As I’ve gained more experienced, my view on engineering excellence has evolved. Early in my career, I did not understand what engineering excellence looked like. I knew the basics of coding. I spent several years building a monster application that eventually became impossible to maintain. Near the end, it got so complicated that making a minor change would cause me extreme anxiety and take a long time.
About ten years into my career, I was introduced to the software craftmanship movement and extreme programming. Practices like pair programming, TDD, Clean Code etc., became my focus.
Every situation was an opportunity to build things well. A code base without tests was one to shun. If I was building something, it would take as long as it would to do it properly. It had to have tests, the code needed to be clean, and it needed to be loosely coupled. Generally, this approach worked well for me. I worked on software in stable businesses, places like banks, insurance agencies and established products where quality and robustness were the focus.
Lately, I’ve worked in organisations and teams that still haven’t got “product-market fit”. The cash runway is a real thing. Knowing that the business/team will cease to exist in the X months/years if the product doesn’t achieve the big hairy audacious goal it is aiming for has evolved my view. I still believe in engineering excellence, but I balance this with the need to build financially viable software that meets business needs.
If I go back to my Extreme Programming roots, one of the principles of Extreme Programming is the principle of economics which explains that software development that doesn’t acknowledge economics risks the hollow victory of a “technical success”. I have a better appreciation of this than ever before.
Businesses need to make trade-offs based on the horizon they are working at. Suppose a business needs to have a shorter-term focus because if it doesn’t hit a certain date, there will be severe repercussions. In that case, I’m fine adjusting the level of engineering excellence appropriate to the time frame with the caveat that if you continually take a short-term view, things will eventually grind to a halt as software takes longer and longer to maintain and enhance.
What is my advice to you as a software engineer? Continue to invest in understanding what excellent software engineering looks like and being able to apply it. You should know the tools at hand and how to build things well. Choosing to intentionally take a short-term view is different from being ignorant and writing poor-quality software because you didn’t know anything better.
