I have been in the Software development business for 42 years in nine different companies. I've seen some projects succeed and far too many flounder. Here are my observations on what went right and what went wrong.
- Why projects succeed
- Continuing contact with the ultimate customer; lots of feedback on prototypes
- Excellent requirement specifications
- Automated Unit and System testing
- Constant emphasis on quality
- Good design
- Good team communication
- A real business case for the project
- Why projects fail
- Bad Requirements
- Wrong Requirements
- Creeping Requirements
These are new requirements that enter the project once it has started. These take a lot of time to retrofit into an existing design. New requirements are always needed in a project, but they should only be accepted if absolutely necessary and the schedule and resources updated.
- Going for the big kill
This is trying to get everything in the first release. This delays the project and prevents initial user feedback. Time is so critical in the software business.
- Slavishly following a programming methodology.
Objects are good. Object Oriented Design is better. Patterns are wonderful. Use these to the maximum extend that it makes sense, but no further.
- Optimizing too early
Trying to make the code really fast and efficient before its working with the essential features.
- Managers putting in features
Putting in cool little features that are not a felt need by the client. Maintenance, documentation, and testing on these features can drag your schedule down and jeopardize your project. I've worked on several projects where cool features were put in early on, and we wasted lots of time maintaining and debugging them.
- Missing one level of indirection
Hard coding the components together instead of using an interface layer. The guts of the components cannot evolve without affecting the other components.
- Not enough internal marketing
Don't assume an obviously better product will prevail. It takes internal marketing and personal initiative to show people.
- "Broken Windows"
A few problems with quality will doom an otherwise good project.
- Bad Requirements
- Why projects don't fail.
- Lazy programmers.
Almost all software developers I have had the pleasure to work with are hard working dedicated individuals.
- Lazy programmers.
- Four Variables of Product Development
The customer can pick any three:
- Cost
Early in the development cycle, you can spend too much money. You can spend not enough later and damage the project. You need a happy medium.
- Time
How long will it take to finish the product
- Quality
Don't sacrifice this one. Programmers really want to produce high quality code. This leads to higher job satisfaction. Oddly enough, a project can often be done in less time, if quality specifications and testing are higher.
- Scope
Scope is the most important variable for software development. Sometimes you cannot control the Cost,Time, or Quality, but if you can control scope, you can increase the odds of a good product.
- Caveat
In addition to these you need to consider your resources. Do you have enough testers, programmers, money, machines, documenters, tools? How can you maximize your resources?. Often you can trade one for another with careful planning.
- Cost
- Miscellaneous Tips
Test rigorously during the development cycle with representative data. I've been burned by testing with small sample sets that worked great, but real life size data sets were too slow. Test constantly with many data sets representing the range of real data using automated tools.
- Quotes
Philippe Kruchten, author of The Rational Unified Process
:
Architecture is not just about building the right UML models, with three, five, or seven views; it is also about people. As I used to tell the architecture team on an air-traffic control project I worked on: Fifty percent of the job of an architect is communications -- communications with other teams, internally, with the customers, with suppliers, with other parts of the company -- twenty percent is planning; and the rest is technical stuff."There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors."
Anders Hejlsberg, designer of C#:
I'm a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don't try and put in place a framework for solving a specific one, because you don't know what that framework should look like.Steve McConnell, author of Code Complete
.:
You'd probably want to tar and feather a teacher who gave you a programming assignment, then changed the assignment as soon as you finished the design, and then changed it again just as you were about to turn in the completed program. Burt that very process is an everyday reality in professional programming.
page 75 of Code Complete"All in all, I think test-first programming is one of the most beneficial software practices to emerge during the past decade..."
page 504 of Code Complete- Hal Fulton
"I've enhanced the gui until it no longer works. This is called 'rebugging'". -from the Austin Ruby Mailing list
Juval Lowy
Modern Software Engineering is the ongoing refinement of ever increasing degreees of decoupling.Amit Asaravala
Management isn't about popularity; it's about respect. Staffs respect leaders who show fairness and justice within a disciplined organization. Great managers are prepared to make unpopular decisions. They're truly great managers when they know an unpopular decision now will lead to success later. They're prepared to wait for the respect born out of success whilst bearing the anxiety of unpopularity in the short term.
"SD PEOPLE & PROJECTS" Jan. 2005: Managing at Microsoft By Amit Asaravala