The Atlantic published an article by Ian Bogost regarding the industry use of "engineering" for software and the relationship of facets in comparisons of disciplines in software creation to disciplines of public project creations such as roads and bridges.
I've been building software for over 30 years now. Quite a long time to watch technologies rise and fall, disciplines come and go, and buzzwords be created from thin air only to fade into extinction almost as quickly as they came.
However I am at times a Software Engineer and during those times I am not - I still aspire to implement process and structures to be called one.
Why only at times? Shouldn't I be a Software Engineer all the time?
Sometimes the proverbial crap doesn't hit the fan the same way twice and as I later will discuss based on the sate of the industry, we don't always get what we want.
Engineering defintion from Merriam-Webster : the work of designing and creating large structures (such as roads and bridges) or new products or systems by using scientific methods; the control or direction of something (such as behavior)
We'll refer to this a bit later.
While I don't completely agree with the author, herein referred to as Ian, and his mindset detailed in the Atlantic article. But instead of going off half cocked about the pride I take in developing software, I realize there are times under sometimes uncontrollable circumstances that actually support Ian's thinking. There are several main ideas running in my head in which I think the arguments can swing either way.
1) Engineering is not just for public efforts and in the public interest and shouldn't be considered only a public infrastructure thing.
This is one aspect that I don't agree with Ian at all - based on the implied definition of "engineering".
Let's think about the history of engineering as depicted in the article. Military and Civil Engineering date back to 1325 AD if the resource I found is correct. Correct or not, I do think it is safe to assume the way we construct machines, buildings, and civil engineering systems has matured over thousands of years, probably since the Egyptians and the Mesopotamians. Sometimes it takes us a humans a while to get something down solid. 4000+ years has done some good things.
With software generally being born around the mid 1950's, it is safe to say that from an engineering approach - software is still in its infancy. Other engineering practices have had a much longer time to incubate and get better. We in software are still babies in the engineering world.
Not all engineering feats benefit the public and is responsible for public safety and reliability. The Manhattan Project had engineers and it certainly didn't adhere to responsibility of public safety and reliability. As I understand nuclear fission is subject to spontaneous reactions. So the perceived notation that engineering adheres to responsible public consumption is a diminished pipe dream at best.
Engineering expands well beyond the implied definition in the article. Sometimes feats of pure engineering happen for the individual. Plenty of DIYers are wiring their homes, installing solar power supplies, constructing buildings, and so on. Many of them are not engineers.
With that however, have you seen some of this work like I have with previous home owners, might not be a bad idea to be certified and licensed.
However Ian hits it on the head with this quote - "Computing has become infrastructure, but it doesn't work like infrastructure."
He is right, as software pros - we don't always get it right and many different fronts. This can lead to....
2) Sometimes engineers across the board jack %$it up.
Ian points out many different software failures within his article. Target, Anthem, and Ashley Madison are among a few of the many companies mentioned in the news lately and have scrambled to repair reputations. We use cloud based services all the time that hiccup and spit up all over the place from time to time. Like the baby reference I just put in there?
When structural engineering was finding its way, there were plenty of similar episodes. If Darwin awards were more like Emmys, we can see awards given for the Tacoma Narrow Bridge, the Bhopal disaster, the Challenger, and the Titanic. These failures happen however and engineers in all disciplines aren't perfect.
While no disaster is acceptable in software or any other engineering discipline, we tend to forgive software more often than not for various imperfections. That in itself doesn't support software working like infrastructure. Like any approach, and as Ian mentions in regards to 'greenwashing' and 'engineerwashing', many issues get covered up through the creation process.
In my mind, the argument for software engineering to be detrimental to it's core engineering based on frequency of failures is ludicrous. All facets of engineering can be improved on practices and execution. I agree though that because of software's infancy, it desires the need to be more organized through consistent scientific practices and standardization would be beneficial to reduce such failures.
3) Old school software career journey versus today's software journey.
This is where Ian and I agree. To quote Ian ->
"But by definition, 'engineering' has traditionally entailed the completion of and Accreditation Board of Engineering and Technology (ABET)-approved 4-year degree."
I'm not sure I agree with the four year degree - I argue it takes much more than a typical standard 4 year degree to establish true expertise in engineering principles. I argue that 8 years plus a journeyman program is needed to properly master and to knowledgeably adhere to many standardized practices to produce high quality functioning software.
With the ease of anyone getting their hands on computers and learning to program them, we are seeing many self-made programmers. Nothing wrong with this, it's how I think most of us start out. I started out this way and grew into the role through practice and education.
The difference as Ian points out is that with minimal skill sets and experiences "engineers" are jumping into startups and focusing on minimal viable products to market. We've become very forgiving to expect updates to recently released software to stabilize features. Because of our quick to market approaches, we sometimes bypass quality measures.
"To 'engineer' is to jury-rig, to get something working more or less, for a time. Sufficiently enough that it serves an immediately obvious purpose, but without concern or perhaps even awareness of its longevity."
Ian describes a MacGyver scrappiness in building software. While I really hate admitting it, we are in a cycle in which getting a product to market, and "improving" on it as it matures in the marketplace, is becoming the standard path.
This can dilute proper production necessities that allow software to be classified as an engineering approach. However, I do disagree with Ian on the following:
"And even successful, methodologies like Scrum never allow that infrastructure to stabilize."
Stabilization is referred to as the lack of tweaks and features on a regular basis. In fact these methodologies in my opinion produce better software when the methodologies are properly adhered to. Frequent additions of features is not an indication of instability of a software solution or product.
As a software industry, we really have been failing at certifications and licensing for practitioners. The major reasoning is agreement to what standards and practices should be adhered to. There are so many flavors to our young industry that it is becoming increasingly difficult to gain industry consistency.
4) Business needs at time outweigh proper techniques and quality - not with just code folks.
We are a order and drive-up to get our goods society. One of the core perceived issues with high quality software is that it takes too much time and costs too much to be cost effective for the enterprise. We want our return on software investment much quicker and in shorter cycles. It is good for fostering an adaptable business environment.
Software is also a discipline that goes well beyond code, and more than likely requires a team of skilled individuals to bring out certain aspects of a particular solution. Every member of the team has a direct reflection on the quality of the next work performed in the project process.
Is this development or engineering? I argue it is in between. Development is really the implementation of design and process through software code. It is certainly far from the social welfare that Ian has stated as a facet of engineering.
But, in a majority of cases it doesn't fit that definition above. The only place it doesn't fit that definition is for "by using scientific methods". We can certainly quantify software in many different measurements. Big O notation, issue counts, cyclomatic complexity and cohesion, maintainability index, and so on. The problem is for the most part - we never even talk about these in business software development. Not until there is a problem.
While there is a scientific basis for software, it is a great facade to demonstrate the art of software. In the past, I've been under the belief that software can be a hybrid of science and art. As I've matured, I realize this isn't the case.
The scientific foundation, including basic logistical concepts in mathematics, are imperative for software engineering to take place. Artistic elements can be placed on top this foundation to make software appealing, particularly code in my context of this article. Code can have a pleasing aesthetic to the eye. Aspects like UX and UI design are typically a completely different, and necessary, type of art form in my opinion.
5) Software Engineering in Practice
So everything leads us to this. Not everyone in every software creation capacity is going to be of an engineer status. The trends in current development practices, in which I agree with Ian, are trending away from engineering principles and encompassing more of a tradesman approach to software.
In my roles in software I would absolutely love to adhere the proper disciplines around particular principles, practices, and incorporate strict quality control metrics 100% of the time.
Alas, I am not an independently wealthy software developer and have to follow the lead to stay within appropriate budgets and scope requirements for clients looking to maximize their investments with short ROI cycles.
This is not a bad thing for software, but those cases are not engineering by definition in real situations. Once the software industry matures to the point in which organization and proper accreditation take place, software engineering will no longer be an outlier of engineering practices.
In my opinion a brotherhood of software engineering professionals backed with proper credentialing will stifle creative software development to a certain extent, but it is a necessity when it comes to properly becoming one of the myriad disciplines of engineering.
Engineering is relating software creation through scientific approaches that can be measured and have been proven to support accountability and proven application of expertise.
Due to many of the debacles in software lately will we circle back to the approaches we started?
I think we will have to at some point and we'll do it in tandem with keeping costs low, consistent and shorter delivery cycles, and being able to reintroduce high quality practices throughout a software project life-cycle. We will apply proper adherence to mutually agreeable metrics in design and implementation.
As I said - we are still babies in this world of software but I'm hoping we can learn from the other disciplines so we don't need 4000 or so years to really get behind it to get it right.