OJ Develops

Thoughts on software development. .NET | C# | Azure

Adaptable Software: Motivation

29 March 2023

There is a pattern that I keep noticing in the software projects that I have been a part of. It’s that 1) the speed with which the software is modified tends to go down over time and 2) the chance of introducing bugs along with the modifications tends to go up over time.

velocity-down-bugs-up

This is a bad thing for everyone involved:

  Software owner Developer Software users
Decrease in velocity Changes of the same complexity cost more to develop Developers are less productive Requested features take longer
Increase in % chance of introducing bugs Implementing bug-free features cost more to develop Focus shifts away from creativity and more toward just making things work Bad experience while using the app

There are many reasons for this, some regarding people practices, some regarding coding practices, and some a little bit of both.

Regardless of the reason, I believe that it is of primary importance to constantly keep these two metrics in mind during the software development process. These two metrics can serve as the guiding light when making both technical and non-technical decisions.

In other words, these two metrics can inform an opinionated approach to developing software.

Here are some questions whose answers are typically hotly debated when asked without context but can be easily answered if those two metrics are the primary consideration:

  1. What software architecture should we go with?
  2. When should we implement automated testing?
  3. When should we set up CI/CD?

If those two metrics were the primary considerations, then in most cases, these would be the answers:

  1. Something that probably does not have elaborate layers or abstractions to begin with
  2. As soon as possible
  3. As soon as possible

From my experience, I would say there’s a non-negligible portion of software where:

  1. The architecture is created with elaborate layers or abstractions to begin with
  2. Automated testing is non-existent, or is an afterthought at best
  3. CI/CD is non-existent, or is an afterthought at best

All of which contribute both to a decrease in velocity and an increase in % chance of introducing bugs.

I believe that having those two metrics as the guiding light throughout the entire software development process would result in a better-looking graph, perhaps one that looks more like this:

velocity-constant-bugs-constant

Which is way better than the first graph I showed.