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?

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?