Software - To Develop or To Engineer?

The other day, in some general reading, I came across a Wikipedia link on “Engineering”. On further reading the article, I found it extremely intriguing that while it listed the following as the main disciplines of Engineering, there was no mention of Software engineering!

•  Chemical engineering
• Civil engineering
• Electrical engineering
• Mechanical engineering
• Aerospace engineering
• Marine engineering
• A few more but NO Software engineering

It got me thinking– why isn’t Software (Information Technology) not spoken of in the same breath as Engineering? Is it still thought of as some Art or Magic (voodoo!) form as opposed to Science? We commonly associate the verb "Develop" with software, but shouldn't software be "Engineered" too?

So, let’s begin by looking at the basic definition of Engineering. A Wiki article defines the term 'Engineer' as - "Engineers, as practitioners of engineering, are professionals who invent, design, analyze, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost."

 While "regulation", "safety" and "cost" may not need much discussion, "practicality" is an important qualifying limitation & constraint that perhaps deserves further disambiguation. "Practicality", as it relates to IT systems/solutions, needs to be seen in the context of the challenges facing corporations like ours in the Software & IT realm. What would those be? Amongst others, the "pace" of evolution or obsolescence would certainly be a top-of-mind recall which brings forth challenges like software life/maintainability, relevance, etc. Now, why those, you may ask... So, let's deep-dive a little more - 

a. Maintainability? This is an industry where nearly every other day there's a new buzzword with much hype, that entice practitioners to try their hands on the new thing so as to remain the smartest & greatest. All good; but corporations can't continuously keep reinventing solutions to their business problems and IT systems need to have a shelf-life before they are sunset, so as to reap the right Returns On Investments already made. This constant push-n-pull between the corporations' needs and the associates' aspirations leads to high level of attrition. So, it's extremely common for us in the IT industry that we often support/maintain software that was developed by someone else and someone else maintains software that we develop. Hence, maintainability is, to me, a huge deal for which we need to necessarily "engineer" software and not just "develop" it.

b. Relevancy? In current times of super-paced evolution in not only customer behaviors & expectations but also the surrounding ecosystems, it's critical that software be designed to be future-proof (well, as much as possible, of course). This needs serious investing of time and effort to not only identify the current business problems but also gaze into a crystal ball to hypothesize & address future business needs. Building robust solutions that will stand the test of time is a key tenet of "engineering".

 Whilst not delving into the many more drivers that surely exist, it should be apparent that it’s not enough to just create software (aka “write spaghetti code") that can address business needs but it's important that "engineering" principles, concepts & patterns are 'systematically' applied to creating software.  Why then should we not ask for and expect software to be Engineered instead of merely Developed? After all, it’s not just bridges that crash!

What then, in our "structured & deliberate" endeavor to creating software solutions, should be the right job description (developer vis-à-vis engineer) used to attract the right talent that can be trusted to solve business problems using software?

A developer would 'implement'; focusing their talents often on a single area, a specific task, or within a specific environment, without necessarily looking at the “bigger picture”. While an engineer would be expected to 'architect', always looking at the “bigger picture”. An engineer can assume the developer role, but an engineer’s core focus lies within the architecture, designing and future-proofing - a "conscious methodical approach" to problem solving... And engineer would treat software development as a “craft that he is constantly trying to improve” rather than a single job to complete.

I did come across a few interesting analogies too -

a) Working as a mechanic does not make one a mechanical engineer, and so writing code does not make one a software engineer.

b) In the 'physical' construction world, the software engineers would be the architects and software developers the contractors.

c) An artist uses paint to apply to a canvas to create his works. But there actually is an engineer at the paint company who engineers the paint. He studies its viscosity, its longevity. He applies science (chemistry) to create new paints, which the artist uses.

While most of what’s written above has probably been well understood for long, I do remain tickled by some of the behaviors and approaches that I continue to see towards building software systems. And that's not limited to the young blokes who are looking for instant gratification, many senior executives that I come across too display this fallacy of a quick-n-dirty solution (aka 'band-aid'). Many argue that software engineering is an idea whose time has come and gone, and software development is, and always will be, somewhat experimental & magical...Surely, engineering is not an alternative to genuine talent & passion, and engineering principles alone can't carry even a moderately complex project through to success. At the same time though, only passion, talent & commitment without structure can take the project (and the budget… and the business...) completely off course! 

The bad thing is, that everyone in the business wants to get “agile”, without knowing that most times the problems are that the companies are not organized appropriately to be “agile” and hence, most remain saddled with a completely wrong time planning. By engineering you can try to get project times, try to plan a project. And perhaps even sell it before you develop it to a customer! I have seen a lot of companies that claim they are using scrum and/or "discover-as-you-go" as a process… but the sad truth is that most use it as excuse to be unorganized, over timeframes, over budget (or worse, don’t know what budget they need and buy new hardware and software every other month to get more performant, but do not see what’s really going wrong). I often think that this is all akin to getting into a taxi and telling the driver “Just Go, we'll think of the destination as we head in some direction”!

 I welcome you to share your views and thoughts on this topic.

And like always, since you have been reading, a big THANK YOU!