The Economics of Protecting the Red Shirts

Recently I came across this post from a fellow lamenting the lack of interest on the part of .Net developers in architecture solutions such as IoC, Dependency Injection, ORMs, and the like.  This stood out in stark contrast to Java developers who this person interviewed, who either were conversant with the technology or were interested enough to pursue informing themselves further.  Some call this the result of Drag -n -Drop design as laid out in a post  by Greg Young, a Microsoft MVP and .Net developer who has specialized in high performance applications.  Greg maintains in his post Java vs. .Net Developers that drag and drop is mis applied and there needs to be an greater effort the isolate the cases where it is mis used.  This practice has arisen, he maintains, from poor training and lack of awareness of other development platforms.

Microsoft has excelled at creating environments where assembling an app quickly is a – gasp – “no-brainer”.  Making it easier to create screens that collect information allows your business to afford a lower priced skill set to achieve “IT” stuff.  The IT guys are a necessary evil, but fortunately they can be easily replaced. This is likened to the poor slub on Star Trek who wore a red shirt when he beamed down on a mission.  Usually a security officer of low grade experience would buy it in the first few minutes of an episode. 72% of the time he wore a red shirt.  Mr.  Expendable-replaceable-low-skills-guy was switched out the next week for another red-shirted phaser target.  And that was okay, because the business of Star Trek was to place the stars in danger and have Shatner take off his shirt.  From a business perspective most of management feels they need “screens” and a “data bank” to store the data.  Microsoft makes it easy because the commercials say so.  Keeping a team of Red-shirts is cheap, in fact it’s good business practice.

From an economic perspective it may make sense to only hire Red-shirts in the short term, as you need to assess what you needs will be.  What most businesses do not realize is that there is a huge technical debt that they incurr when letting a Red-shirt drive the spaceship without supervision.  Fresh out of the academy and their trusty new phaser in their hand the Red-shirt is not even aware of the dangers in store for them.  That’s why McCoy never, ever let them in Sick Bay unless they were hurt.  Dirty secret was that they rarely made it to Sick Bay as in many cases they were simply vaproized.

Stated in terms that a business cares about, you incurr a “technical” debt when you high cheap, uni-dimensional technical staff to just make screens and save stuff in Sharepoint.  This debt is fine as long as you can make the payments; that is, as long as you are not reliant on maleable solutions where consistency of data is of importance.  Quick screens will create pockets of data that are not easily correlated, and when you want to ask the question “How can I relate the accounts maintained by the sales screens to the accounts that we send invoices”, you will find that you have a “red alert” on your hands.  Why?  The information will in many cases not be stored in a fashion that allows it to be associated with other critical information.  You see, a Red Shirt can not perform surgery.  They can only their phaser and be vaporized.  Stated another way, in the short term the cost for someone to create an application has been avoided, but in the long term the cost to fix this problem has grown way beyond this initial expense.

Many of us have entered into IT via the Microsoft route.  Yes, the majority of us were all mostly Red Shirts at one time.  The Microsoft Starfleet Academy has helped many people in countless ways, but there is a risk that you only serve on one type of vessel.  Each individual needs to actively seek out not the new ways of painting screens, but focus instead on what practices have been in place in the software development field as a whole and not just what happened last week on the Starship IT.  A more arduous task is to identify how software development can assist the critical bottom line of businesses by selecting a solution that is an off-the-shelf package, or more critically, when you need to identify a solution that can flexibly meet critical needs in the long term.  Explaining this to businesses can be very hard, and as a practioner of the ActiveEngine, you’ll need to develop this critical communication skill so you can stay off the Red Shirt Roster.