- Bad management.
- Bad management, again.
- Bad design.
- Lack of test-cases.
This was, in my opinion, a solid breakdown of the fundamental risks associated with any engineering endeavor.
My response in both cases is that from my viewpoint they are both oversimplifying the issue. Engineering, in software terms, is the process of converting information into focused tasks and then executing those tasks. But is this what most non-computer engineers would tell you? For example, social engineers, mechanical engineers, even sanitation engineers? Okay, that last one was a little extreme. But my point is we want to put people in buckets. This is something I will always resist in almost any scenario. I just find it rarely ever is productive, but more negatively it reinforces a behavior of isolationism or elitism. These are two of my sworn enemies, but that's a topic for another post. ;-)
The implication in both posts is that they were focusing primarily on software engineers; people who make computer programs. An evolution that has been underway for most of electronic history is breaking down the walls between the analysts or business savvy types and those who can actually create the solutions required by the analysts or business savvy types. The largest software construction engine on the planet is focused on precisely this task. It started way back even before the days of Visual Basic when they were finally able to let just about anyone draw forms and tables on screen without programming. This same evolution continues today in virtually every business product line released, and in many that aren't just for business. Why else would you consistently see advertisements and spam for DVD-ripping software, or graphics editing programs? Do you really think the average in-duh-vidual grasps even a small percentage of how a DVD system works? With the help of software they don't have to. We have removed the necessity for them to have information while enabling them to be independently productive.
What both posts should have been focusing on, again just MHO; is that the art of creating great software and elegant systems falls into the domain of Architects and Designers. In the structural and mechanical industries we call these the Engineers and even require licenses for them. Those people who follow the rules and instructions and execute the steps to construct the finished product are technicians or laborers. If you want to talk about Engineering, don't confuse it with technical labor. If you have issues with the process of development, you have to seperate the implementation from the plan. Until we solidify a mindset that properly seperates these two distinct functions and abilities, the software industry will continue to fall prey to these generalizations and devaluations.
Of course, being primarily an Architect myself, maybe this is just my own form of hypocritical elitism.