In an earlier email I asked you on your opinions as to what you would like to read more about. A bit like a “chose-your-own-adventure” style newsletter. BTW: Did you see that show on Netflix, where you can decide how the story unfolds? This was excellent. Although the nerd in me sees many ways how it was confusing for the user and how it could have been even better. But for a TV show? Wow, I am excited that dared to do that!

Anyway, the majority of the answers indicated that you would like to read something about testing strategies.

In a call I had yesterday, I used the phrase “In a small company, every app becomes a legacy app”. Small companies often don’t have the time or money to test their apps properly. Sometimes the knowledge on how to design and code an application isn’t evenly distributed in the team. Peer review might not prevent mistakes or bad decisions (again: time and money). The state of an application gets worse, the longer it is maintained. When I come to a company with little or no tests and they ask what they should do, I often recommend to create a small risk assessment for the features of their app. Once you know the critical paths through an app and the risks for each you can start to test these features outside-in. Critical paths with high risk differ from case to case, but things like “password forgotten” and “shopping cart payment” are candidates that rank high all the time.

Ideally you would have unit tests for your classes. And integration tests for multiple components. In reality you have nothing. So don’t try to test from the inside, but start at the edges of the application for your critical paths with high risk. Write acceptance tests for these parts. Keep it to one or two tests of the “happy path” where everything works. Once these are covered you can decide whether to start a refactoring or add more tests. More tests could mean “sad paths” as well, or unit tests for some of the more modular components.

This will help you gain certainty that you don’t break your most important features when you start the bigger refactoring. These are also tests that management should have no problem green-lighting because they prevent errors for the parts where money is earned.