Quick, tell me what is common between, “” and Software Engineering?   Answer: They are both stories about engineering and one has tragedy in human lives.

The Tragedy at Second Narrows is an absolutely compelling story about engineering design. The tragedy is the number of lives lost due to what appears to be an engineering design oversight.  Ironworkers Memorial is of very special meaning to me as I live near Vancouver and occasionally have the privilege to drive over the Ironworkers Memorial Bridge.  I have a lot of respect for the Ironworkers, Engineers and the entire craftsman who worked on this piece of art.  The art is that traffic flows across the bridge at the same speed as the #1 Highway in Canada – the user experience is seamless and that’s its beauty, it is also by design (i.e. it has been engineered that way).

The Ironworkers Memorial Bridge also has a special meaning to me as it relates to software engineering.  I believe software design and development is an engineering activity.  In fact, the more years I do this (since 1977 in electronics engineering and slowly moving to software engineering since 1991) the more I believe it.  So do others, including educational institutions. You can get a 4 year degree in Software Engineering  and the States have been doing since 1996 when I saw it at RIT while working at Eastman Kodak in Rochester, NY.  Damn man, you can even get a PhD in Software Engineering.

Software Engineering in the province of BC is recognized as a professional practice and since 1999, you can apply to APEGBC to become a licensed Professional Software Engineer.  Aside from having an ABET recognized 4 year engineering degree, 4 years documented experience, 4 P. Eng.’s to stand up and vouch for your sorry ass, attend a 2 day law and ethics seminar or consume the equivalent in CD-ROM, and pass a 2 hour Professional Practice examine, there are additional requirements.  You need to fill out a Software Engineering Checklist and you need to complete the Software Engineering Experience Guidelines. 

It is very interesting to read over the last two documents, Software Engineering Checklist and Software Engineering Experience Guidelines.  The point being, if you want or need a description of what Software Engineering is and how to document it, spend a bit of time reading these short documents.  While a bit old, the first principles hold true, which is what I refer to the lost art in my title (more later). 

As mentioned previously, Software Engineering is a recognized professional practice in British Columbia.  Check out the benefits of becoming a licensed Professional Software Engineer. Meet the first licensed Software Engineer, Philippe Krutchen, who was licensed in 1999 in BC.

Software Engineering to many people have many different meanings.  Some think/feel software development or programming is an artistic endeavor.  Others think of it as craftsmanship. From my perspective, I agree with everyone. In fact, it is all those things and much more. Some people feel that the La Sagrada Famillia is art.  Some would say the craftsmanship that went into it was second to none.  But it was also engineered (i.e. designed). Check this out, Gaudi designed the weight-bearing of his buildings, upside-down with string and bearings.  So when you looked in the mirror, of course it was right side up.  I saw this first hand.  Engineering at its finest, well before modern engineering with all our fancy calculators and our StarTrek Communicators. 

So Software Engineering is design, art, craftsmanship and any other word that people want to use that is not engineering.  Call it what you will, I agree with you.  But it is also part engineering.  That to me is the lost art, specifically the engineering design part.

In fact, I would say Software Engineering, at its very core, has four fundamental activities: requirements analysis, design, code, and test.  Of course you have to deploy and operate, maintain, and a whole pile of other things (reports, UI enhancements, skinning, ad infinitum), but I just want examine these four core activities.  Let’s put some definition around what I am getting at:

• Requirements Analysis:  I don’t care if you use story points, scenarios, use cases, flowcharts, or animated puppets to gather and package software requirements.  The question is how accurate is your transformation and how good you are at repeating it.  Understand what I mean?  How do we as a team communicate “what” needs to be built?  To answer the question, I am suggesting use whatever methods and tools you want as long as the result (i.e. the transformation) is accurate and you can repeat that accuracy on multiple projects consistently and eventually, predictable.  That to me is the lost art of software engineering in requirements analysis.  What is the percentage accuracy of our requirements gathering and packaging? i.e. relative to the intent of what the users actually require.  And btw, if the users or community can’t tell you, in gory detail, what they want, then no amount of software is going to solve the problem.  Capiche?  What’s our percentage repeatability and predictability?  That’s the theory and in practice it does works.  But it is a lot of very hard work, so you really don’t see it too often in our field, hence the lost art.

• Design: Ah, the crux of software engineering.  Your choice of design methods and tools should be determined on which methods and tools will result in the least complex, but most (easily) extensible design possible.  In short, at its essence is a mathematical formula for reducing complexity, but the art is your application of the formula at the problem at hand.  Again how accurate is your design transformation relative to the requirements you used to produce that design?  Can you do it consistently as new and old problems come your way?  Whether you choose a formal design method like MIT’s Alloy, (if you have never used Alloy before, try it on for size, it really demonstrates software complexity through modeling. ) or a traditional OOD method, is really not the ultimate issue here – choose whatever method/tool yields the most accurate Requirements -> Design transformation.

• Code – it seems everyone knows how to code in their favorite programming language.  Again ultimately, from a software engineering perspective, use whatever programming language yields the least complex representation or transformation of the design.  Oh, yeah, I know what about the human factor – where are we going to find programmers?  Or the million other factors that occur when selecting a programming language. Does it really matter?  Not if you want to produce the least complex implementation.

•  Test – There seems to be a dazillion and one testing methodologies/tools. Does it really matter which one you use or what tool?  I don’t think so.  Again, what percentage accuracy is our testing against the 3 previous transformations? Oh sure, at what level of effort you ask? What was the requirement for testing accuracy and coverage?  Don’t have one, better get one.  More lost art.

Oh, I know I am greatly simplifying the above, but isn't that a lost art also?  It seems to me that year after year we further complicate our art, not simplify it.  One lost art of software engineering is trying for the most accurate transformations from requirements to test (and eventually deployment, operations, and maintenance.).

Another lost art it seems is designing for a least complexity solution or at least making it a priority.  But that takes time, commitment and data.  And that’s my point.  It appears the trend I see in our industry, and if Jeff Atwood’s blog on Software Engineering: Dead  is any indicator, reading the comments there are an eye opening experience about people’s thoughts on Software Engineering.  I have been there myself, on more than one occasion, and in fact, is normal for most companies that are trying to design software, but really don’t know how.

The only way to improve what we do as Software Engineers is to measure what we do and how we do it.  Oh sure, that old tired saw.  I have seen it work with my own eyes to know the truth and value behind it.  Yet, we as an industry seem to have completely forgotten the value of measuring what we do and how we do it.  Other industrialized industries would cease to function without this feedback control loop.  Can you imagine pro sports without stats? It would never happen, but the trend in our industry seems to be moving away from measuring anything and just going for it.  I wonder why that is?

My hope is that over time Software Engineering, while a Professional Practice in British Columbia, becomes more widespread, and what I used to take for granted as standard operating procedure (SOP) in Electronics Engineering, will become SOP in Software Engineering.  But like anything, this is going to take time and education, particularly for folks that don’t know about the engineering part, or for others like me that have lost it from time to time.