Straw poll time. Rank these factors in order of how much effect they have on whether or not a project will succeed:
- Good documentation.
- Choice of implementation language.
- Good (and plentiful) hardware.
- Coding skills of team members.
- Quality of project management.
- Automated tests.
- Clean, well-organized code.
- Choice of framework or tools (aside from language).
- Non-rushed deadline.
My take
jplindstrom on 2007-09-14T00:10:59
Something like this:
- Mature supporting infrastructure.
- Coding skills of team members.
- Quality of project management.
- Non-rushed deadline.
- Clean, well-organized code.
- Choice of framework or tools (aside from language).
- Choice of implementation language.
- Good (and plentiful) hardware.
- Good documentation.
Notice how I sneakily expanded "just tests" to encompass the whole concept of supporting tools, e.g. automated tests, version control, continous integration, etc.
Project size would also belong somewhere near the top of the list.
Item 0: Competent, clued in people who reflect upon what they do.
From that, all else follows.
Good people
brian_d_foy on 2007-09-14T00:24:07
jplindstrom beat me to the punch. I'd vote for his item 0. Good people ensure that the right stuff happens. I like to emphasize that projecs are people doing something. It's not some abstract thing on a managers white board.
:)
challenging...
jonswar on 2007-09-14T03:45:04
Quality of project management.
CLASS of implementation language - e.g. agile versus ancient
Automated tests.
Choice of framework or tools (aside from language).
Coding skills of team members.
Good documentation.
Clean, well-organized code.
Good (and plentiful) hardware.
Non-rushed deadline.
This was challenging. Many of these items would doom a project if completely missing, but matter far less if they are merely substandard. I would much rather have adequate levels of all of these than great on some and terrible on others.
good question!
lachoy on 2007-09-14T04:21:09
Here's mine:
1. Coding skills of team members.
2. Good (and plentiful) hardware.
3. Choice of framework or tools (aside from language).
4. Automated tests.
5. Clean, well-organized code.
6. Choice of implementation language.
7. Good documentation.
8. Quality of project management.
9. Non-rushed deadline.
I tend to agree with Bill de Hora that source control, a build system, and issue tracking are more important than most people (particularly non-developers) credit. Poor ones act as an anchor on anything you do, particularly on larger projects.
here's my shot
mpeters on 2007-09-14T14:54:32
1. Automated Tests
2. Clean, well-organized code.
3. Quality of project management
4. Good documentation
5. Coding skills of team members
6. Non-rushed deadline
7. Good (and plentiful) hardware
8. Choice of implementation language
9. Choice of framework or tools (aside from language)
My take.
jk2addict on 2007-09-14T15:24:12
1. Quality of project management.
2. Good documentation.
3. Automated tests.
4. Clean, well-organized code.
5. Coding skills of team members.
6. Non-rushed deadline.
7. Choice of framework or tools (aside from language).
8. Choice of implementation language.
9. Good (and plentiful) hardware.
If no one is leading, things go nuts.
Lead can't happen without docs (requirements at least). Testing tracks intent, documentation, and regression. Skliz can be learned/aquired, and poor skils can be overcome with good testing and clean code.
Let's introduce some real numbers...
btilly on 2007-09-14T22:01:38
Let me pull out my handy copy of
Software Estimation by, of course, Steve McConnell. On page 67 he has a nice chart of the average impact of different ratings factors on the development of a 100,000 line of code project. Their factors do not map directly to your list, but here is my best attempt to map it.
- Good documentation. This reflects the Requirements Analyst Capability, which has an impact factor of 2.00.
- Coding skills of team members. Maps to Programmer Capability (General), a factor of 1.76.
- Choice of framework or tools (aside from language). Closest choice is Use of Software Tools which has an impact of 1.50. Note that experience with your tools also has an impact of 1.43.
- Quality of project management. Maps best to Process Maturity, which has a factor of 1.43.
- Clean, well-organized code. Maps best to Developed for Reuse which has an impact of 1.31. Note that this is the impact on development time. No estimate is available on the impact on maintenance (which is what you really wanted to know).
I couldn't find a good mapping in that table for the following factors:
- Good (and plentiful) hardware.
- Choice of implementation language.
- Non-rushed deadline.
- Automated tests.
I put those in the order that I'd personally value them at for a smallish project.
Better late than never
Phred on 2007-10-02T03:47:33
My take on this:
- 1. Quality of project management; I think nobody wants to admit it, but good management is crucial for setting end goals and keeping the minutae out of your way
- 2. Automated tests; this is absolutely crucial, you can't ship unless 100% of tests are passing.
- 3. Coding skills of team members; good coders imply that 2) will happen on its own
- 4. Choice of implementation language; you can't write a high performance firewall in php, for instance (not to pick on php)
- 5. Good (and plentiful) hardware; having hardware that is consistently slow or crashes just plain kills morale
- 6. Good documentation; not so important for the initial launch but if this project requires any maintenance this is essential
- 7. Non rushed deadline; it's good to have time to think things through but you don't want to take forever
- 8. Choice of framework or tools; I think the reason I put this here is because I just assume that everyone wants to use the same framework as me :) I've worked with some frameworks that have been really painful to maintain, but fast to develop with, so I guess that the framework is more important to maintenance than initial project success.
- 9. Clean, well-organized code; this is important definitely, but I've learned that good coders can work their way through bad code. Although I've seen code (I'm sure everyone has) that takes hours to figure out what's going on.