Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I've been making small scale projects for a while now. I haven't started a large project, yet, because I haven't come across anything which I needed and wasn't already accomplished by some other FOSS. Until now. I want to make a program which will allow users to interactively learn secondary languages (I'm kind of want to make it as close to Rosetta Stone as I can).
Right now I'm the only developer since I'm not sure if I'm biting of more than I can chew and don't want to waste any contributors time.
So far I've been planning how the project is going to work and setting up tools to make the project start smoothly and for it to be readily accessible for when other users are ready to contribute to it. I've set up a SourceForge account, a git repository, as well as a document which lists all the features and what the program is going to accomplish.
A basic break down is that the suite is going to be written in java, and the suite will have the ability to support many languages via their locale. The courses for learning the languages will be written in jython. Course-makers will have the ability to use pre-made jython courses to teach their course, or make their own original ones. I'm hoping this will allow for the software to teach copious languages via many mother tongues.
I'm also planning on having a repository of "released courses" which are ones which I (or people who better comprehend the language) think are top-notch courses. This will hopefully make the program seem more professional and secure to the users while allowing third party participation.
With this in mind:
Are there any fatal flaws or suggestions about my project you would like to make?
Is there anything I'm missing about making a big project in general?
Thank you for your time and effort,
Joseph Pond
You will always be biting off more than you can chew if you don't believe other people should consider your project worth their time. This is much more of a leadership point than a programming point. But seriously, work it out: is this idea something that you believe can happen even knowing that you are currently unprepared for many of the challenges that you are about to face? You've given us a rough outline. You'll be giving others a more thorough explanation, and it will soon become obvious that you've overlooked some stuff. Nobody can keep that from happening to you. Having said that, if you think that you have a good grasp of the requirements of most of the components and you believe you can thoroughly describe the requirements to others with appropriate skills, I'd say go for it.
P.S. -- If you have any mock-ups, that would make it seem like a sweet deal from a prospective developer's perspective. It sounds like the selling point is the extensibility of easily designing new courses. If that's so, give an idea of the basic structure of the Jython. When my supervisor gives me a task that I understand thoroughly, I'd rather he didn't show me how to get started or what design or implementation to use. When I have no idea what he's talking about, the roughest of sketches gives me days of a head start.
Are you also the only analyst, translator, technical writer, and tester? This sounds like a large undertaking for one person. Do you have a deadline? In my opinion you will need at least another developer and tester. Even more if you have tight deadlines.
Just find the right person who really agrees with your idea and will take the ownership.
I had been involved in several projects but I dropped out some and only worked on the one I really interested in. So, look at it in the reverse side, looking for a contributor is not easy and must find the person has the things I mentioned about. Then, you can talk about keep contact,, system... project manage..etc. If you can't find the right person, even you have a good system, you are just wasting your time and going nowhere.
Okay, a couple things. First, it's better never to do a big project. Do lots of small projects instead. If it works out that what you get at the end is a big thing, that's good.
Second, a lot of times what works best for this of thing is to think about how you can make something to make it all easier. in this case, you have two issues: making something that does the various operations needed to display and give feedback (I'm working through a Rosetta Stone course myself, they're pretty cool.)
You're really thinking about a course authoring system; you can't write all the materials for all the languages, so you have to make it easy to do the authoring.
This sounds like a job for a DSL, a domain specific language.
And it sounds like a really cool idea.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I recently started a career in software development after graduating a couple of years ago in CS. The current project I'm on is a large ongoing project that has it's origins in the 90s with a mix of C, C++, and Java. There are multiple platforms (UNIX, WIN, etc) being supported, older technologies in use like CVS, and some dated documentation in some areas.
The extent of my software development skills stem from going to university as I've had little real world experience. I felt like I had a decent foundation in CS but I cannot but help feel slightly overwhelmed by it all. I'm excited to be part of something so huge but at the same time I feel like it's a lot of information to absorb.
My coworkers have been great people and answer a lot of questions I. My employer hired me knowing that I am entry level.
I've tried poking around the source code and examining how everything gets built but it's on a scale I've never seen before.
How do more experienced people situate themselves when joining a large ongoing project? What are some common tasks you do when getting yourself up to speed?
Good question. I haven't had your exact experience, but in cases like this I like to think, "how do you eat a whale?" The answer is (predictably) "one bite at a time." Reasonable people won't expect you to grasp the whole thing immediately, but they will want to see progress. Perhaps there are some small areas of the larger project that are not too complex, without too many dependencies. Work toward understanding one of those and you're one 'bite' (and/or 'byte') closer to expertise on the whole project.
Being familiar with all existing documentation I would try to get the big picture. Literally.
generate a TreeMap of the source code
I would use GrandPerspective on Mac or WinDirStat on Windows. It will give you some insights about the structure of the project's files (sometimes it gives some hints about the code structure). Having this, you can ask your colleagues for some of the clusters, what they do, how they relate to each other.
learn how to build the project
This is important to have it compiling all the time if you are about to do any changes. Having tests executed at the build time is always a good thing, so ask for it also. Even better if there is some kind of continuous integration server in place. If there is, look at its configuration - figure out how the build is done. If there was no CI server, but you already got the knowledge how to build the project, create such a server on your local machine, and show it to your fellows - they should fell in love with it.
browse the source code with Structure101 or similar tool
This is useful especially for Java projects. This tool does great job. That will give you more details about the code structure, and sometimes about the system architecture. This experience may be sometimes hard, you may learn from this tool that a code is basically a Big Ball of Mud ;)
look for tests, and explore them
If you will be lucky there may be some JUnit, or CPPUnit tests. This is always good to try to understand what those tests are doing. It may be a good starting point to explore the code further.
My coworkers have been great people
and answer a lot of questions I. My
employer hired me knowing that I am
entry level.
You have little to worry about, you're employer knows what you are capable of and your co-workers seem eager to help you out - to be honest most developers love explaining things to others...
From what I've seen, it take truly 6+ years to become fully knowledgeable in a language, so don't expect to become a guru within a year... and even these so called gurus end up learning something new about their language everyday.
Learning a new system (large) will always take time.... the systems were usually not built in 2 weeks but over many years, so don't expect to understand it fully yet. You'll eventually discover what each part does piece by piece.
I know how you feel, because I felt like that once...
"I took a speed reading course and read 'War and Peace' in twenty minutes. It involves Russia." (Woody Allen)
I agree on what the others said before me. You need some tools that give you an overview on the code. I personally used inFusion (http://www.intooitus.com/inFusion) because it gives also other interesting data beside structure.
The method that has worked best for me is to grab a copy from source control, with the intention of throwing this version away...
Then try and refactor the code. It is even better if you can refactor the code that you know you will be working on at a later stage.
The reason this is effective is because:
refactoring gives you a goal for you to aim towards. Whereas "playing" an "breaking" the code is great - it is unfocused.
To refactor code you really have to understand the code.
Refactored code leaves code that has less concepts to retain in memory. If you don't understand a large codebase its not because you are a graduate - its because nobody can retain more than 7 (give or take a few) concepts at a time.
If you follow correct refactoring guidelines it means you will be writing tests. Although, make sure that you will be working on the modules that you are testing as writing tests can be very time consumning (although very rewarding)
Do invest in buying this book at some point:
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672
But these links should get you started:
Signs that your code needs refactoring and what refacoring to use (From Refactoring - Martin Fowler)
http://industriallogic.com/papers/smellstorefactorings.pdf
A taxonomy of code smells:
http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
Good luck!!!
I agree to the first comment but I also Think that you have to learn and see the big picture in some way. You have to trace the main flow from code at least.
I was in the exact same situation several years ago when I joined a software project with 50+ ClearCase version control vobs, 5 million lines of code, and some of it dating back to the 1980's.
The first thing I did was look through every source controlled directory and made a quick summary of my best guess about what the software in that folder did and what language the code was. You can make a pretty good guess by looking at filenames and any comments or documents in those folders.
I then looked at the build scripts to see if they were readable enough to get an idea of dependencies between different parts of the code.
Finally - and I believe this was the most valuable - throw an IDE like Eclipse or NetBeans on top of the code and start reading through pieces of it. Having the ability to jump to the definition of any functions or classes using the IDE allows you to move around a massive software baseline with relative ease.
Overall, have some confidence - it is unlikely that anyone else on the project knows all of the code, so you don't need to either. Use what other people said to get a good idea of the overall project and interfaces and requirements (if they exist) and poke through the code to get an idea of the most commonly used classes and methods.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Hey all. I would like to get some insight on a question that I have been trying to find some information about. If you are the solo developer that is building a project from ground up, how do you manage the project? In the past, I have worked on a few personal projects that have grown into fairly large projects. In almost all of those projects, I have tried to wear the hats of all the roles that would normally be in place during a normal software development project (i.e. Product Owner, developer, architect, tester, etc.). It seems that when I leave the project for some time and come back, it is extremely hard to get back into the rhythm of what I was doing. So with that, I have some questions:
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
If this is the case, are full blown product backlogs or use cases a little overkill?
How does one efficiently appropriate
his/her time to each respective role?
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into
OOA/D?
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
Basically, I was curious how everyone out there in the SO community would go about developing a project from inception to deployment when you are the lone, solo developer. What steps, documentation, and other project related activities are needed to help bring this project from an impractical, hobby project to something more professional? Any help, references, or suggestions would be greatly appreciated. Thanks in advance.
The most difficult part, I have found, about developing solo is that it's just tough to keep yourself driving forward. Even if you're doing this to make a living (AKA, running your own software business), unless you have pressing needs (AKA, you're going to starve if you don't make money) it can be difficult to sit down and just code.
From your perspective, I would recommend following good software practices where it makes sense to. For example, if I were a solo software developer, I would have no reason to create a collaborative development environment. All I really need is an SVN server, my IDE, and a place to record documentation (might setup a wiki or a website or something). I would personally create a realistic schedule to follow and would work on sticking to that.
As for level of effort of documentation, that really depends on you and the product you are developing. For example, I would definitely recommend recording your requirements. Unless your product is trivial, there is no way you'll remember them all and why you wanted certain ones over others. Managing a full backlog, however, can be a job in and of itself. In the solo programmer case this may not make sense.
Basically, the point I'm trying to get across (and should be followed with every project - not just in this case) is have just enough management that makes sense. The rest should be focused on the work and the development of the product.
Something else you may want to look into is reading this - Agile Programming Works for the Solo Developer. There are other, similar, articles out there. Might give you some good thoughts.
If I know the requirements (at this
current time), do I record them
anyways? If so, how do I go about
doing this, and how do I manage these
requirements? Product backlog,
features list, etc?
I have two lists of features:
A high-level view which states the scope of the finished product
A list of the features which I'm implementing in this iteration
Because I don't need to communicate it to other people (yet) I tend to write down the things that I don't know about the project (if I already know it there's no need to write it down): it's when it gets too complicated, or when there are details which I haven't defined but need to define, that I start to define them in writing.
I did however try to investigate/make a business-case for the project before starting coding.
How does one efficiently appropriate
his/her time to each respective role?
I did non-programmer, product-owner thinking at times when I had to be away from the computer anyway.
Apart from that, my cycle is:
Implement more functionality
Integration-test it
[repeat as above]
Every 3 to 6 months I compare the new-functionality-accomplished against my estimated schedule, and then recalibrate: i.e., make a new list of the highest-priority features to implement in the next few months.
What would be a normal flow of events
that one would follow? Start coding
immediately, write down user
stories/use cases, then go into OOA/D?
I started with working part-time or in my spare time, to make sure that I had:
Understood the required functionality
Made significant architectural decisions
Written any throw-away prototypes as necessary to learn new technology
After that I was ready to start developing full-time.
What diagramming/modeling would be sufficient for this level? Domain model, class diagram, etc?
I'm not using diagrams at all (except for sketches of the UI). By structuring the code, and refactoring, I'm able to know/remember/rediscover/decide which software components implement what functionality.
It seems that when I leave the project
for some time and come back, it is
extremely hard to get back into the
rhythm of what I was doing.
You need to comment your code more. If you leave the code, come back in two weeks, and can't remember how the code works, you need more comments.
If I know the requirements (at this
current time), do I record them
anyways?
Yes, for the same reasons stated above.
how do I manage these requirements?
A feature list is OK, provided you have enough detail in each feature to jog your memory.
How does one efficiently appropriate
his/her time to each respective role?
Break down each feature into smaller and smaller tasks, until you feel like you can do each task in a half day or less.
What would be a normal flow of events
that one would follow?
That depends on your development style. In general I would follow a clear but simple architecture, avail yourself of software patterns where practical, and provide adequate unit tests for your code as you go.
What diagramming/modeling would be
sufficient for this level?
Sufficient diagramming/modeling to make the project clear in your head.
What steps, documentation, and other
project related activities are needed
to help bring this project from an
impractical, hobby project to
something more professional?
Other than what I have already mentioned, make sure you have a good source control system and daily backups in place.
Good luck!
If you believe there is a chance that you're going to work on the project for some amount of time, leave it, and then come back to it at a later date...your best bet is to treat the documentation for the project the same as if you were working with a large team.
That means documenting requirements (even if they're from yourself), writing use cases (if functionality is going to be complex, otherwise some other form of documentation could suffice), and some level of UML diagraming (or other domain specific diagram) which could include activity diagrams/class diagrams/etc.
That way, when you leave the project for some amount of time, you can come back to a well documented idea and pick up where you left off.
As a side note, I try to do the majority of those things no matter what...that way if I ever find somebody interested in working on the project with me, I can get them up to speed quickly and get them on board with my ideas.
This is how I work, YMMV:
Keep a spreadsheet for high level of everything - list of your projects, and some top-level items/todos/reminders
Create a "project" folder for each product/project you have or work on, and create a strucuture to contain documentation and code for the project.
Keep a top-level "catch-all" document for each project, in the root of this folder. Keep you ideas, research, notes etc in this doc.
Then if you want to get organized, keep an MS project file (or similar) and plot out timelines for the various steps in each project. This is good for tracking progress on each project and make sure you arent forgetting anything. Basically keeps you honest with yourself.
And if you need to track progress on project work you are doing for clients, I understand Basecamp is a good solution for this. I am currently evaluating it for my own company. See www.basecamphq.com
Even as a solo developer, you should document at least the overall features of your project, and then the requirements for the particular feature you are working to complete, and then maybe produce a short pseudo-code for the functionality you're currently working on.
That way, if you do end up breaking away from that project, you can get back to it and see where you're up to easily enough. It's also pointless getting too far ahead of yourself with details for this same reason.
It's also a neat motivational tool for a solo developer - getting through and ticking things off is a way to show progress - something that you can start to feel you're not making when you're chewing through a couple of thousand lines of code and it seems like you're still miles away from actually having 'module x' completed.
Lastly - with regards to code comments - I at least try and fill out what actions/behaviour a new function should have in an outline, and then write the code in between the comments. Also, it is useful having plain English explanations of why you're branching in an if/else to support the logic in the condition...
I belive that better results in solo development one can achive with appropriate tools support and tasks that compensate lack of ohers people and help to organize working time. Any tool that generate metada with minimal create time cost describing your software is helpful.
VCS and tools for tracking user actity/code changes history - very important is to add good commit messages
mind-mapping tools for storing project related data (e.g. XMind), blacboard is useful too :)
time tracking tools (e.g. Toggl.com)
write a lot of acceptance test and use acceptance testing frameworks
Of course these clues also fits in non solo development :)
As a lone developer, I've found that your time is very expensive. This means that you have to balance sustainability and momentum - even though you are just one guy, you have to do things so that the you six months from now can go back and look at old stuff without wasting time, without spending so much time maintaining the systems that it compromises your flow.
Your question suggests that you are thinking in terms of fairly heavyweight tools and processes, but the 80/20 rule applies - for example, you can nail documentation well enough by TDD, using the doc tools of your platform to generate API docs, plus a Wiki for specs, lists, etc.
In that vein, I would suggest that you choose your platform carefully. The question about modelling suggests that you are using a platform that produce a lot of code and artifacts, but you may be able to get most of the functionality for much less management overhead elsewhere. Today I'm working on a .NET Web app that I wrote "the right way", but now realize that I could have delivered the same functionality much more efficiently in this case by using PHP with a PHP MVC framework to keep a clean structure.
Specific tools that I'd recommend:
A distributed version control system (much less overhead than centralized)
The most lightweight platform that you can use that has good tooling
A Wiki to easily capture and maintain small and large bits of content
Whatever testing framework that you can use, right from the start of the project
A lightweight TODO list system that you can access from anywhere
I used to work on a very small team (one dba and one C# developer). Even then I found it very useful to have written requirements, formal tests, source control and bug tracking (we used bug tracking for our features as well as bugs). It helped us to not forget anything and a year later when you were doing maintenance, you had something to research though to help you undersatnd what you did. Plus when the two of us left (as most people eventually move on) there was documentation there for the next person.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I was recently working with a team to develop an online system. We had worked for several months and were making good progress when the project got canned. We all felt strongly that the projects completion was important and that it would have great outcomes on our consumers productivity. After being frustrated for a while I thought I should ask some people with more experience.
What is the best way to deal with the frustration of a canned project and move forward so that it doesn't hold future possibilities back?
On a well designed project, some of the code you developed can be reused in future projects, making it worthwhile. Even if you can't use any of it however, you and your team probably gained valuable experience that will help in the future as well. Think of it as an expensive team exercise.
Don't put your heart and soul into someone else's project?
I do a lot of work for different people and while some projects are more interesting than others they're not my projects so I wouldn't be too broken up if they got canned. I've got my own stuff I'm working on. No one can terminate those projects but me.
Grieve. Such a loss will produce a grief reaction. Not one as strong as though you had lost a loved one, but it's a grief reaction nonetheless, complete with all those stages of grief.
Failure is the best (and sometimes only) way to learn new things, even if the failure is not your fault. There are many different angles by which you can salvage useful information from this:
Code that is reusable
New technologies or skills garnered from the project
Lessons about project management based on how the failure was handled (maybe the project should have been canceled much sooner, before the team bought into it)
Non-technical ideas that you can reuse in other projects for the company or even in your own endeavors.
I highly recommend doing a postmortem, but don't dwell. Most projects get canned at some point in their cycle and if you let it affect your morale, it becomes a downward spiral from which it's hard to recover. You may become oversensitive to even slight requirements changes.
Attack every project as though it were your own. By this I don't mean invest all of your emotions (as stated here already by Spencer Ruport). But write all your code and organize all your code in a manner that you can easily pull out tools that you might need in the future. You never know if you will need it...but odds are you will. If you write an account manager app...do it in a modular reuseable fashion. If you write an image uploader...write it in a way that it can be ported to any other project you have. Write helper functions around all of your major features to make it more user friendly down the road.
This of course requires some planning prior to losing the gig! No worries. It rarely is because of you that you (the whole team) loses the gig. Some financial decision or business decision is usually at play. In this case most likely the economy is what killed you. In the case that you don't have any physical benefits to the failed project...look at it as a learning experience. Inevitably...no matter how good you are...you probably had something that you did that you don't or no longer agree with. Learn from that. You most likely also did something very cool that you loved. BLOG ABOUT IT! This serves two purposes..you just created something tangible from the project...and you put it somewhere that you won't forget about it.
Sucks all the way around. But at least there is a great market out there right now! Contact me directly if you want my headhunter list (80 technical recruiters in CA and the US).
Two things:
Your Investment in the Project & Code: The fact your team had such strong feelings for the project & were so frustrated on it being canned is a good sign - it means you are a true developer/programmer and are not just doing a half-job for full-pay. So to deal with the project being canned: know you & your team are committed to your work & while that project may not have panned out, you guys sound like a real credit to that project & any other you may work on. It sounds like you just need to find a project/opportunity that has the legs.
My Experience: Projects get canned for all sorts of reasons - budget, lack of confidence from stakeholders, too late to market, changed scope etc. I would enquiry/investigate why your project was canned. If it is budget or lack of stakeholder confidence then it is really good news. It means an opportunity has just presented itself to you & your team. Consider pursuing it!
Either way your team will have grown from the experience: both technically & from a business perspective.
cash the paycheck - that always helps ;-)
ask if you can have the rights to the canned project, since they don't want it, then open-source or commercialize it yourself if you think it's worthy
it's good to care about your work; it's not so good to obsess over it.
there will be other projects even better than that one in the future; they might also get canned, for any number of reasons both rational and irrational
Good example: I once worked with a lady who spent 2 years on a document-imaging project that was canned a few days before it was supposed to go live; it was canned because the new manager did not like the old manager, and the project was his "pet". This lady's reaction: "I'm looking forward to learning something new!"
This can be used to bring your team closer together, if you have the right sort of people. There is nothing quite like working hard on something you believe in and then having it canned. It can depress, but it can also motivate people to want to prove next time that they can do the job, that they had the right idea.
It helps to galvanize the team; we were there, we worked hard, and it was taken from us.
Of course, it's better not to be in that situation to start with, but when you find yourself there use it to build the team.
Sunk cost cannot be used as a reason for the continuance of a project. If the leaders have made a business decision then I'm sure that it is well motivated, however upsetting.
I'd console yourself in that big swings should be celebrated in business, big companies do not win every bid and complete every project they start. So console yourself in having lost once, maybe you might be able to change the way things were done, or focus more on the project stakeholders as well to make sure they understand why your project is worth completing compared to the other projects and business initiatives at the company.
I'll finish with my favourite saying:
"Good judgement comes from experience. Experience comes from bad judgement."
Learn from it!
Watch a Rocky movie (the last one was good) and have a few beers. There's no way not to put yourself into a project, there's no way to not feel bad about a project being terminated or failing, there's no way not to feel negative about the company. What makes a good programmer better is taking all the emotions, anger, etc. and being able to release it and move on with the same focus and dedication that was there with the first project. All part of life and all part of working in IT.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
What steps can one take to mitigate the risk of a one-person team working on a project, especially when that one person is a rather junior programmer?
I ask because I am that junior programmer, and there is no one available/willing to do things like code reviews. Part of the problem, I suppose, is that I am working on web applications in an embedded software company, so most employees' expertise is in a different area.
Recognising this as a problem is more than most "junior programmers" would be able to do :)
Unfortunately most employers don't see the benefits (only the downsides) in multiple people on the same task.
With lack of understanding from your employer on this point, just stick to all the usual rules, such automated testing, documentation, and source control. I know too well that when working alone on a project, it is all too easy to become complacent.
The truth is that the documentation is not just to help others know what your code does. It helps you too. Source control is not just to enable multiple people to work on a project and merge changes, it helps productivity (in the sense that you can easily revert changes), enforces backups, and gives you good tracking of where your time and effort has been spent.
Source control and automated tests are two things that will help in any environment. Those two things alone will mitigate some of the major disasters (lost work, buggy code resulting from constant changes and refactoring).
Beyond that, stick to the basics: K.I.S.S. Keep your code design as simple as possible, keep your classes simple, follow the Single Responsibility Principle and above all, avoid duplication (which will greatly guide your designs). Make use of every resource you have: message boards, other programmers at other companies, friends from school, whatever you have available to you. Even having a mentor you can send e-mail to is helpful.
Best practices aren't much different than for a larger group. Source control, unit testing, follow a style guide for your language, script everything instead of using manual processes, and try to have at least some high level documentation and comments in the tricky parts of code. For specific decisions that are important and hard to change, like how your code interacts with the database, try to find out what approach a well-designed project uses, if necessary by checking on this site.
Unit tests especially are a great way for other people to quickly figure out how your code is supposed to behave, and to check whether their changes have broken anything.
StackOverflow is full of available and willing people to help solve problems and give advice.
Other than that, be prepared to make mistakes and learn from them.
Oh yeah, and get a copy of Code Complete!
As #MattJ mentioned, the fact that you care enough to try to mitigate that risk implies much more seniority than your current job title purports.
I would say that you should do all of the normal things you do to mitigate risk and, where it's not possible to get another resource, just either do it yourself, or skip that step.
It's the best you can do.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
There are numerous Agile software development methods. Which ones have you used in practice to deliver a successful project, and how did the method contribute to that success?
I've been involved with quite a few organisations which claimed to work in an 'agile' way, and their processed usually seemed to be base on XP (extreme programming), but none of them ever followed anywhere near all the practices.
That said, I can probably comment on a few of the XP practices
Unit testing seems to prove very useful if it's done from the start of a project, but it seems very difficult to come into an existing code-base and start trying to add unit tests. If you get the opportunity to start from scratch, test driven development is a real help.
Continuous integration seems to be a really good thing (or rather, the lack of it is really bad). That said, the organisations I've seen have usually been so small as to make any other approach seem foolish.
User story cards are nice in that it's great to have a physical object to throw around for prioritisation, but they're not nearly detailed enough unless your developer really knows the domain, or you've got an onsite customer (which I've never actually seen).
Standup meetings tend to be really useful for new team members to get to know everyone, and what they work on. The old hands very quickly slack off, and just say things like 'I'm still working on X', which they've been doing for the past week - It takes a strong leader to force them to delve into details.
Refactoring is now a really misused term, but when you've got sufficient unit tests, it's really useful to conceptually separate the activity of 'changing the design of the existing code without changing the functionality' from 'adding new functionality'
Scrum because it shows where the slackers are. It also identifies much faster that the business unit usually doesn't have a clue what they really want delivered
Scrum.
The daily standup meeting is a great way to make sure things stay on track and progress is being made. I also think it's key to get the product/market folks involved in the process in a real, meaningful way. It'll create a more collaborative environment and removes a lot of the adversarial garbage that comes up when the product team and the dev teams are separate "silos".
Having regular retrospectives is a great way to help a team become more effective/agile.
More than adhering to a specific flavor of Agile this practice can help a team identify what is working well and adapt to a changing environment.
Just make sure the person running the retrospective knows what he/she is doing otherwise it can degenerate into a complaining session.
There are a number of exercises you can take a team through to help them reflect and extract value from the retrospective. I suggest listening to the interview with Linda Rising on Software Engineering Radio for a good introduction.
Do a Google search for "Heartbeat retrospectives" for more information.
I've been working with a team using XP and Scrum practices sprinkled with some lean. It's been very productive.
Daily Standup- helps us keep complete track of what and where everyone is working on.
Pair Programming- has improved our code base and helped remove "silly" bugs being introduced into the system.
iterative development- using 1 week iterations has helped up improve our velocity by setting more direct goals which has also helped us size requirements
TDD- has helped me change my way of programming, now I don't write any code that doesn't fix a broken test and I don't write any test that doesn't have a clearly defined requirement. We've also been using executable requirements which has really helped devs and BAs reach requirements understandings.
kanban boards- show in real time where we are. We have one for the Milestone as well as the current iteration. At a glance you can see what is left to do and what's being done and what's done and accepted. If you don't report in your daily standup something pertaining to what's on the board you have explaining to do.
co-located team- everyone is up to speed and on page with what everyone else is doing. communication is just-in-time, very productive, I don't miss my cube at all.