The tragic shift away from engineering thinking to developer thinking.
Not to give off “back in my day” vibes, but kinda totally giving off “back in my day vibes,” things were done a bit differently. Sure, some of those things were legit pants-on-head stupid (a story for a different day), but overall, we focused on software engineering. Over the years I’ve noticed a shift in the software industry and how teams go about solving problems. Folks aren’t (in general) thinking and approaching problems like an engineer and instead are thinking and approaching problems like a developer. (Side note: most companies claim they want the former, but secretly prefer the latter.)
What does “approaching problems like an engineer” mean? Well, I’m glad you asked!
Engineering, as a discipline, applies knowledge, theoretical or otherwise, in a particular area to solve real-world problems. As such, it requires a particular level of rigor: understanding a system thoroughly, especially its limits; how it will behave under those limits so that we can establish thresholds of tolerance to ensure it doesn’t fail/break/fall over easily. Imagine designing and building a bridge. Engineering requires understanding how much traffic will be going over it, the type of vehicles traversing it, the distance spanned, the types of materials used, the structural design, local weather patterns, the type of terrain it will be built on, etc. Without all of that information we’d be unable to build a structure that would be verifiably safe to use; we’d be participating in construction roulette.
What does this have to do with software? Well, designing and writing software requires this level of rigor even more than building in the physical world. Say what now? Yup! Why? Well, for those of you not in technology, computing has its roots in mathematics. Computing and computers were tools used in the aid of solving mathematical problems, e.g. processing census data. This strong tie to mathematics remains to this day. You see, software is very abstract. There are a billion and one ways to solve a problem. That is part of its appeal to those of us in the field: it’s an incredibly creative process that is grounded in logic and problem solving.
The issue is compounded by modern computers being incredibly complex machines that handle tremendous amounts of data. You see, computers are deterministic systems. A deterministic system is one in which a given initial state or condition will always produce the same results, with no randomness or variation in the ways that inputs get delivered as outputs. That means put the same thing into the system 5 billion times, you know what you’re going to get out every single time. However, going back to how complex and powerful computers have become, our software has also become increasingly large and complex. All of the interactions between our modern computing systems and the software that’s running on them in conjunction with the volume of data they handle renders the entire system effectively non-deterministic. It’s why we have crashes. It’s why there are bugs.
This is why we need to apply engineering thinking and rigor to software design and development. We need to understand limits and tolerances so that we don’t have crashes and software is always safe to use. It’s why we need to define process and tooling so that we create predictability in our systems. Over the last 20+ years I’ve seen this approach to software development erode.
What has this erosion looked like? There isn’t a single thing we can easily point to as the root cause. It’s an entire system of changes.
If I were forced to point to a single point of origin, I’d blame universities. They fight to entice students to choose one institution over another in order to have the largest student body because Universities have become businesses. They do this by offering programs that are appealing to prospective students and also to businesses. Businesses just care about cranking things out prioritize rapid delivery of features and products to their customers in order to expand as quickly as possible and gain the largest market share. This is especially true in those organizations that aren’t engineering centric and where Product Management and/or Finance runs the show (pew pew, shots fired!). There are many issues stemming from this approach, but a couple really stand out:
- Businesses focus on solving problems that don’t exit whose sole value is that some executive is excited about it (AI, anyone?).
- Engineers end up looking for other ways to express their technical creativity and they do so by choosing technology that is often unnecessary, overly complex, or a flavor of the month at <insert your favorite FAANG here>.
This hyper focus on “delivering features” has been a contributor to the erosion of engineering and instead has pushed for just cranking out code. This has often resulted in sacrificing testing to deliver “value,” sacrificing writing valuable commit messages to deliver “value,” sacrificing taking a step back and understanding the problem they need to solve, and to design a solution that solves that problem. Just like with muscles, skills atrophy over time, and thus a developer (dev) is born. Queue that oldie but a goodie, Code Monkey. The resulting dev lacks curiosity in understanding their craft and how to apply it in a way that leads to simple, clean, maintainable, high quality, extensible solutions. They are lazy in all the wrong ways (read this to understand what virtues you should be aiming for as a software engineer; also, maybe pick up Perl if you haven’t already done so. Just sayin’.).
To be fair, there are a few traps that devs and engineers share. The biggest one is probably chasing shiny things. This is a symptom of not understanding that businesses are businesses and are there to make money. They ultimately don’t care about cool tech. A business wants to solve a problem in a way that can be exchanged for money. Now, this doesn’t mean we can’t use cool tech, we just need to understand how it helps the business. But this gets into the territory of another post: “Engineers should learn how to speak another language: Product Management”.
So, to wrap this all up, the software industry is not in a great spot. Businesses have eroded many of the critical aspects required to make software development viable, for both the business and for the engineers themselves. Those of us who have been around for a while, regardless of whether you’re an Individual Contributor or in a People Leadership position, should be leading by example to help shift culture at work to be engineering strong and Product/Business focused.
I am Cranky Old, born four hundred years ago in the Highlands of Scotland. I am Immortal and I am not alone.