Modern Software Development
On why we should stop treating software development as a branch of Engineering
It’s important to know what something is in order to deal with it correctly.
Have we mistakenly treated software development as a branch of Engineering for years?
Arguably hundreds of millions of dollars were lost chasing the wrong things.
Wrongfully treating software development as Engineering would explain the horrible failures of Six Sigma and other methodologies - including Scrum - in software development.
I’m going to structure this in two parts.
Dave Farley’s argument
Dave Farley's main argument for software development as a branch of Engineering - and please correct me if I'm wrong - is that we can measure software development, and measurement makes it Engineering.
To a certain extent, that is true - you can measure things at a team level or company level with DORA metrics and other similar QoS tools.
Deployment frequency
Lead time for changes
Change failure rate
Time to restore service
On an individual level attempting to measure anything is a fool's errand.
Every time we have tried to do so we have failed as metrics become goals.
Measure lines of code and you’re going to get code diarrhea, measure mouse movements and you’re going to get people using mouse jigglers etc.
Measurements are ubiquitous
Measurement, however, is not unique to Engineering.
Your tailor does measurements, your cook, your car repair shop and all branches of science: Physics, Chemistry etc. - and none of these are Engineering.
So, indeed, you can measure aspects of software development starting at team level, but measurement does not convert development to Engineering.
So what does? What makes Engineering Engineering?
The act of programming could be considered Engineering only if and when it deals exclusively with Knowns!
This is the light bulb moment - this is the one-liner to take from all of this.
When software development deals only with known variables it becomes Engineering.
Thus PaaS, software deployment, software distribution, networking - and everything else that "gets done 1000 times per day" - that is Engineering, and you’re welcome to borrow engineering best practices like Six Sigma and others.
You can have a Network Engineer managing networking hardware and software. The TCP/IP protocol doesn’t change overnight.
But the person writing a totally new transport layer over HTTP2, for example - that’s a software developer.
We're all, constantly and forever Researchers or Developers.