Smart People Choke Under Pressure

LiveScience had an article about how Smart People Choke Under Pressure. In usually good form, this was picked up and picked apart by Slashdot. You can find some pretty insightful, humorous postings by a wide variety of in-duh-viduals. This particular article wasn't particularly arousing but it did get an interesting discussion about people who prefer to think creatively vs. rigidly; people who want to follow rules vs. people who prefer to ignore them, etc. At one point, some brainiac brought up the notion that engineers in general want to shy away from broad problems prefering highly focused tasks. Duh! Anyone who is essentially PAID TO THINK will desire specific deliverables to showcase the value of the effort. Without something specific to output we are at risk of not appearing useful. The poster must have been a managerial type because they tried to redeem themselves saying that the more you can work without information the more valuable you are. Rubbish. He basically tried to reason that McDonald's employees are more valuable than a geneticist working to cure cancer. Once again the Beast of Complete Ignorance has seduced yet another unwitting victim. The good news is that I was saved from having to retort by the rest of the Slashdot masses who quickly, relentlessly, and with prejudice handled the matter. One particularly good response induced me to write this entry. Essentially, the thesis on "why engineers want information" can be broken into a combination of four things. You really should read the full post, but here's the super condensed list:

1. Bad management.
2. Bad management, again.
3. Bad design.
4. 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.