Intro
In my Interim CTO career I’ve often seen software systems that were quickly developed and delivered to clients with great fanfare. Some of these systems were successful for a very long time.
But some of them failed miserably after release and had to be rewritten from the ground up. Some even caused companies to fail.
Most of these failures were caused by the wrong approach to develop software. It’s the difference between “programming” and “engineering” that makes all the difference.
Programming
Programmers write code. They finish the task. They move on. Many agencies you’ll contract will work exactly like that.
The problem with that approach is that there is no long-term perspective. Just hacking something together can be ok for a quick prototype. But it will kill your business when that code is used by clients.
The symptoms of a “programming” attitude are:
- You have single engineers doing things alone and not in a team.
- Tasks get assigned to a person, not a team.
- You have a lot of emergencies in your department that can only be fixed by one person.
- The same outages happen over and over again. Root problems don’t get fixed
- Parts of your application are unstable and stay unstable after multiple interventions.
- Teams complain about outdated software and slow developer experience, but nothing is being done about it.
Engineering
Engineering is vastly different to programming. Unfortunately, engineering is hard to notice on management level. Good engineering means that systems work without any problems. New requirements are being done by reliable teams. No heroes fixing problems, no screaming - just a very calm focused creation of great features for your business.
Good engineering means to not only write the code, but to also make sure the code is usable in the long run. This means that a stable team is created around a codebase. Best practices are established. Single points of failures are an absolute exception.
All systems are designed for a longer lifetime. Something like security, software upgrades or outdated libraries are never a problem.
The symptoms:
- The product teams develop cool stuff constantly with high quality.
- It’s never a problem if someone goes on vacation.
- Post-Mortems are done to make sure mistakes don’t get repeated.
- Emergencies are an absolute exception - and the same bugs don’t appear again and again.
Conclusion
When you are in the game for the long run then programming is not the right approach. It is very risky and will kill your business eventually.
The solution is to do real engineering and also hire real engineers that make sure your business is successful in the long run.
More
- Image on top by Darpan at https://unsplash.com/photos/gray-concrete-bridge-across-the-mountain-kGpZUqKlvx0
