Discussion on:

Avoid these classic software development mistakes

I've seen projects where they are making a game and they make the game up as they code along. Without designing the game first, you are doomed to failure.

Ccfman is spot-on. I know of a company which wanted to outsource a major database development because the in-house database was limited in its capabilities and the company didn't have the internal resources to do the necessary development. The company doing the development was never given a specification other than a verbal chat of what was required. The new database delivery date was quoted as 6 months from start but in reality it took over 2 years with ridiculous numbers of changes and corrections, many of which had to be paid for on top of the initial cost because they hadn't been specified initially. It was a classic example of how not to run a project.

and are easily solved...

"Everybody" knows these, no one does anything about them aside from publishing a list of don'ts like this. They have, are and will keep on happening, because the requirements for developing and managing software and the requirements for selling or using it are very different and parties at both ends keep refusing to admit that.

Far too few people who don't understand both technical debt and ROI and their impact on each other, for instance

Thanks for posting this, Justin, I think developers really need as much support as possible in this area. Numbers 3, 4, 5 are especially contentious with business. Managers expect to be able to schedule software development like constructing buildings. They don't seem to understand that 1) when constructing the building the design phase has already been completed (75%) of entire project time and 2) buildings aren't software and issues can be encountered that were not anticipated in design.

Looking back on my software development history the most prominent aspect seems to be contention about development times and it continues. It can hurt your self esteem and lead to even greater discontinuity of understanding with business if the programmer doesn't realise it's not his fault and therefore can't articulate the problems involved in realistic scheduling.