I recently discussed variability as being software developments' nemesis.  One item I mentioned was that from a single vendor, Microsoft, there are seven user interface technologies to choose from.  My point is that there should only be one. Really, really.

 

The software game is a whacky biz to be sure.  All the way from iPods being dispensed by vending machines to the FBI scrapping the development of $170 million worth of software.  The recipe for success in the software world is just as variable as programmer productivity is trying to stay on top of the ever changing world of technology, let alone developing expert level skill sets in any one area.  As BarryV points out in his comment to my last post, I need a longer ferry ride

 

This variability becomes (much) greater when executives are making decisions about software projects/products without any real idea as to how software is designed and constructed or how it works as a finished product. It is a complete mystery to them, yet, they are in charge.  Ok, this is a blanket statement, but I have found more often than not that this is a truism in our industry.  I am not laying blame, just making an observation.

 

So what's the issue?  Education is a major factor.  Education about software development, which in most cases, is truly an exercise in trial and error, given the newness of our industry and the variability in everything that is software.  Btw, our trial and error software development process is a key reality point for anyone in our industry to fully understand.  And I don't mean trial and error in the traditional sense of just guessing at what to do.  It is more like guessing which way is the best way to accomplish any given set of tasks because there is so much overlapping technology to choose from, which also happens to be constantly changing.   For any given technology, especially programming languages, there are hundreds of ways to solve the same problem, some better than others, but all valid with no right or wrong way.

 

The so-called Software Architect is supposed to be the person that can figure this out.  Being employed as one, I say it ain't so easy.  For example, Microsoft has seven user interface technologies to choose from.  How does one become expert in each one of these so when the task comes to develop a user interface, you make the right choice based on the requirements?

 

From an executives point of view, why should they know this or even care?  They should care as it directly impacts the total cost of ownership (TCO) of the software being developed, which the executive is ultimately responsible for.  If the software gets born and is useful to the target user community, (in which our industry track record is less than stellar) it is usually around for a long time. Bug fixes, enhancements and general maintenance usually make up the bulk of TCO. Therefore strategic planning in technology selection is just as important as developing the software itself. 

 

Millions chose Visual Basic 6 to develop their business applications in.  However, there is no easy upgrade path to .NET.  I know of one large organization that has over 100 VB6 apps developed and running their business.  They are now pondering how to move to .NET not only from a technology perspective, but also from a training perspective.  Caught between a rock and a hard place as the TCO here is stratospheric no matter how you cut it.   Btw, the idea for this org is to consolidate many of the VB6 application functionalities into .NET shared components which will reduce the numbers of apps (and therefore maintenance costs), hence the transition.

 

So what does this have to do with why don't they get it?  The why don't they get it question is usually asked of me by fellow programmers that have seen an executive business decision made that makes no business sense at all.  In fact, I have asked that question myself many times while working for various companies that don't see what I (or other technology savvy) people see. What we see as part of any project is targeting the software development on the latest possible technology.  Immediately executives think, the programmers just want to work on the cool new technology and tools.  Yes, that is true, but you know why?  Usually the latest and greatest tools allow me to do my job faster, better and cheaper in some cases only the next technology makes something possible.  This also translates into lower TCO as the software moves though its lifecycle.  And most importantly, the life expectancy of whatever software that has been born has some chance living a full life, Instead of being re-architected in 3 years, when we may get +5 years using a different technology set.  Even longer if the technology chosen has a technology roadmap that shows it has a future as well.  This is what most executives dont get when in charge of software development, and have not come from a programming background.

 

On rare occasions I have seen a planned technology roadmap that goes along with whatever project or product roadmap that has been developed.  Typically, once the software (ever makes) goes into production, any technology upgrades are extremely low on anyones list.  Then the bug fixes and enhancements ensue.  Over a time frame with no technology upgrades and/or refactoring the design, the software bits that got glued on eventually start dropping off or crush the architecture and the cost of bug fixes and/or enhancements goes exponential.  And then the project or product gets "re-architected" as a matter of course.  More often than not, on some new technology with no technology roadmap.  The cycle continues.  How to break that cycle?

 

One way is demand better and fewer tools/products from Vendors.  As a software developer, I dont need a new or different hammer every year and an entirely new toolbox of tools or frameworks every couple of years.  Know what I mean?  This person gets it.    Also, if vendors consolidate and simplify their product lines instead of making even more product variations will help promote the industrialization of software.  Even though I use Microsoft technologies, I am unimpressed at the many overlapping technologies and different editions or versions of the same.  Can you decipher how many editions of Visual Studio 2005 are from this blog?  There are 5 editions of XP and now 5 versions of Vista.  This is just the client OS!  10 versions, ridiculous, why not just one?  Sure I get the capitalistic thing, but capitalism also can be had with efficiency.  Our software development world is far, far, far from being efficient.  Sounds like a vendor opportunity to me.

 

In case it is not clear, the they in why dont they get it are executive/management people in software development decision making positions that have no background in software development - the process of or programming in.  A super-charged topic even for the largest software company in the world.  Next post I will discuss some of those why they dont get it decisions from the field.  To use Dave Barrys phrase, this really happened!