DJ1.0 is a contributing editor of TechDarkSide.com. We don’t know much about DJ1.0, since he participates in the dark side anonymously. We suspect DJ1.0 is a “he” since he refers to a wife in an early post, but then again, maybe they’re from Massachusetts… Either way, you can reach DJ1.0 at email@example.com.
For most of my career, I have always been told that academia was an ivory tower. Everyone had their head in the clouds and was completely removed from the realities of day to day life. The business world, I was told, live and die day to day by real decisions made real people in the real world. Academics focus on ideas in a pretend world, businesses focus on delivery in the real one. Having worked and researched in both environments for a long time, I think most have it backwards.
I can’t tell you how many times in the “business world” I have heard (and sometimes used) a phrase like “We need to synergize our core competencies by providing an flexible abstraction layer of reusable components and agile business processes. “ I can’t tell you how many hundreds of Visio diagrams I have seen in corporate America with a magic fantasy pipe which goes into a magic fantasy application neither of which exists. In fact, I know of example after example of real businesses making real decisions based on gut feelings, personal egos, desires of what a fantasy world should look like and pure stupidly.
To be sure, academia has all of these traits. They also have a culture and system of empiricism to counter-balance these otherwise inevitable side effects when people deal with data. I can personally attest that during my thesis research, I had to use an entirely new level of rigor. If more corporations used data as rigorously as academia, better and less disconnected business decisions would be made.
There are some who say that software engineering IS a rigorous data-driven science. Software engineers like to use that phrase because it implies a level of discipline similar to engineering. I disagree. As a former double E, I can attest that almost nothing done day to day in software development remotely approaches the level of rigor required of formal engineering.
This might insult some CS people. It shouldn’t and it is not meant to. I also have a CS degree. Anyone who has read Knuth knows there is a lot of science involved. But software development, ESPECIALLY the way it is done in corporate IT, bears little resemblance to engineering.
When was the last time a programmer was sued because his accidental software error caused a crash? In fact, if you read most EULAs, you are explicitly releasing the software company from any and all liability. The EULA for XP says, “Except for a refund…YOU ARE NOT ENTITLED TO ANY DAMAGES.” It further says, “THERE IS NO WARRENTY OR CONDITION OF ANY KIND.” Try that in engineering. “Look, I finished building your house, but if it caves in and smashes your family into tiny bits, don’t come crying to me.”
What I am proposing is a return to a certain level of rigor common in other disciplines that is often abandoned in corporate IT.
In my next post, I will present some specific examples of rigor extracted from my experience in engineering and academic research that could greatly benefit business in the real world.