A/Such a simple thing, but it’s far more complex than it appears on the surface. Having spent many years in the code mines I have a first hand view of the nightmare that software devleopment has become.

Key issues. They largest problem is management. Frequently people manage software projects that are utterly clueless about the technology. They will order nonsensical things like allowing users to modify the primary key,

Time spent in meetings. Once the specs are hammered out many developers are excellent to go. Programming is nearly an art form and when you are in the groove the last thing you want to do is step away from it, go sit down at some waste of time meeting which often has nothing to do with the machinate or if it does is just rehashing what you are doing. If you get ANYTHING productive out of a meeting it’s something that may possibly have been done in a non-real time fashion such as a forum, in email or offlines on IM.

The ancient adage of tape the specs to the top of the pizza box and slide it under the door really is right for the majority of programmers. The less they are disturbed the better they work. Often programmers find their most productive time outside office hours. So pointy haired bossed unable to evaluate employees in any other way than seeing their smiling face promptly at 8am really don’t know programming. It is not raw hours but productive hours. Coders are like other creative endeavors. Some days they are in a hot groove and that groove follows no schedule, respects no power and is reasonably fragile. Bother a programmer to death and you wipe out their ability to code that day. Not just meetings but saddling them with jr coders, PR jobs, a waste of time documentation completely unrelated to the machinate or that isn’t necessary to the code completion.

Programmers are often trapped in pits of red tape. The DB refusing crucial changes just to demonstrate it is THEIR DB not the developers. The inability to get the hardware for hard software or to build test DBs since all too often the DBA is too “busy: to set up a test environment.

Worthless specs is a frequent problem in software development. Some people should not ever even reflect about glancing at specs much less writing them. Far too often people who write specs are not programmers and have no clue about technology. They will spec out the impossible and miss simple to add features. The ignorance of those writing specs can be astounding sometimes. It is often clear that the spec writer never once talked to the client or more often they talked to the administrator who has never done the job that the software is being designed to be used by. Far too often I will write code right to specs then when the client sees it they freak. Then after meeting with the end client I learn I wasted nearly every minute of the time I spent writing that code as it was spec’d so poorly.

Frequently when you go from a legacy system you just export the bugs from one software system to another since those bugs are logic flaws caused by poor specs and or system design and very tight requirements were followed. If you question for something and get it, then why complain?

I had to leave the code mines before I strangled a pointy haired boss. I loved coding, loved the design and specs but the stupidity of the administration I had to deal with company after company the whole lack of technical understanding by CIOs, machinate managers and the politics that were all too often embedded into projects drove me nuts. I really had somebody tell me they may possibly not give me crucial data because their boss didn;’t like my boss. I’ve lived far too many Dilbert moments and may possibly take it no more.

Q was/Is software development a manyheaded monster ? Incidents from earlier legacy systems keep reappearing.?