An unpleasant scene from Cool Hand Luke, but also represents the sorry state of our software industry is in today.

 

Here is a pictorial example of what I am talking about which represents software design at its finest:

 

 

Even the customer could not explain what s/he needed.  Whats wrong with this picture?  Even though it is something as trivial as a swing on a tree, everyone has their own ideas as to what the words mean because we dont have a way of visualizing what the software should be.

 

Had the customer drawn the picture, rather than describing it with words, which is what we usually do in gathering software requirements, then the outcome may have been different.  In fact, that is the key.  Look at the picture again, everyone knows what the customer really needed.  So whats wrong again?

 

The current state of the art in software engineering has us describing customer virtual requirements using words.  Even worse, once we have the words then software designers (architects, programmers, whatever) use highly specialized drawings that mean nothing to anyone but the person who drew it.  We cant even share some of these drawings with our fellow programmers because even they may misinterpret the drawing depending on the dialect and that persons training for that language.

 

What the software industry needs is a way to draw software so that all of the participants can understand the picture.  What that looks like, I dont know, because it has not been invented yet.

So why do we throw software together as described in the previous post?  Aside from our software industry being very young, we still have no way to visualize the size and complexity of any computer software.
 
Think of it this way, building architects use blueprints to visualize and construct buildings. They are full fidelity drawings that describe the size and complexity of any building structure.  Even a person that cant read blueprints can easily distinguish the size and complexity difference between a house and the Empire State building.
 
Yet, in software, nothing like this exists today. We are still at such a low level of abstraction that even professional programmers have a difficult time envisioning software architectures (i.e. the size and complexity of the software structure that we are to design and construct) let alone trying to explain it to someone non-technical, like a customer who cant understand why his/or her software is going to cost so much and take so long to design and build.  If we could show them a blueprint that they could understand...
 
Software seemingly defies the laws of physics as it is all virtual.  That it is why it is imperative for our industry to develop higher levels of abstractions as discussed in David Frankels excellent article, Software Industrialization and the New IT. 

 

We need an AutoCAD like tool for designing software blueprints.  If we can draw the software architecture in full fidelity, similar to any other engineering CAD drawings, then we are getting closer to moving our industry out of the dark ages and into the 21st century.

 

Then maybe we can apply some software engineering techniques as we have a real way to model software instead of the hammer and chisels we now have.  AutoCAD revolutionized the engineering design industry with a Computer-Aided Design (CAD) package in the mid 1980s.  I wonder who is going to invent this for the software world?  And when?

Someone asked me the other day why the need for software industrialization and to give an example of whats wrong.  Here is one trivial example.  I have a new washing machine that is run by software.  Fully programmable!  The user interface is interesting, but that is another topic of discussion.  Here is the problem, once it is all finished it beeps at me every minute with three beeps.  It seems that I need to actually hit a button to say that machine, you are all done.  Ridiculous!

 

So I decided to see if I wait long enough, it will just shut off by itself.  So I let it go for an hour listening to its 3 beeps every minute for an hour.  Thats 180 beeps.  OK, maybe I aint so bright, but I just about took my sledge hammer to the thing to shut it up.

 

I looked in the owners manual to see if this is normal behavior.  First of all the owners manual is 27 pages!  Its a washer, how complicated can it be?  Next under a section called Acoustic Signal was the magic key combination to turn the sound off.  Of course, would have never guessed this without reading the manual.

 

And thats the point of why software industrialization, its a frickin washing machine!  How many millions of washing machines have been designed and produced over the years and I still need to read a manual for one?  Why cant there be just one button that says Start or Go!  Thats a feature I want in my next washing machine, but it seems its going to take a software revolution to get this one feature.

 

Oh, by the way, my stove timer does the same thing it does not automatically turn off, I actually have to go over and click cancel (with my finger) or it beeps three times every minute.  Now where did I put my sledgehammer

I came across this article, Software Engineering, Not Computer Science while researching Software Industrialization, the subject matter of this blog site.  Steve McConnell has written many good books, most notably, Code Complete.

 

Steve asks the interesting question, "should professional software development be engineering?"

 

Good question and I am sure the debate will continue for years.  Even though I am a firm believer of engineering practices, I believe that our industry is still too young to have developed any real solid engineering practices.  Even today, I feel like I still am using a hammer and chisel to develop software the tools suck and it is going to take forever.

 

So what about all of the modern methodologies and practices?  Well, my training in software engineering still defies what I do in my day job.  It is more akin to this approach:

 

"Absolutely the only way I know to succeed with an innovative product is to throw something together quickly, push it out the door, persuade some lunatic early-adopters to start using it, and then rapidly evolve it on a quick turnaround cycle based on market acceptance and driven by a wish list from actual users.  Every successful product I have been involved with, either as a developer or as a user, seems to have followed this path."  From John Walker, inventor of AutoCAD.

 

John calls this, old time engineering philosophy. However, I still do it everyday, even though I am thoroughly trained in software engineering I end up always throwing stuff together.  Why is that?