> But it’s no silver bullet: your software is not going to crash and burn if you don’t write your tests first, and the presence of tests alone does not mean you

> But it’s no silver bullet: your software is not going to crash and burn if you don’t write your tests first, and the presence of tests alone does not mean you won’t have maintainability issues. > It was not our priority early on. Now that we have had a product up and running successfully for many years, it’s time to pay more attention to it. This is a hard earned lesson but one that is firmly rooted in the reality of the industry IMO. I’ve had the good fortune of working on a few greenfield products and bringing them to market. Time and time again I see technical and executive leadership steer teams in this direction. The fact is that writing good tests is hard and expensive. And most new software products survive less than a handful of years. Accepting this reality will help ease the pain of working on that spaghetti codebase at your day job. At least it did for me. Good on stackoverflow for paying back some tech debt in their successful product. I certainly appreciate the tradeoffs that come with building a business, but they can be difficult to swallow for engineers who take pride in producing high quality and well tested code.