Articles for category: Delivery

The Goal in Your Test Cases

The goal in your test cases is to validate a problem that has been solved. It starts with understanding the problem and reproducing it. If you don’t know the problem you can’t reproduce it. If you can’t reproduce it, you can’t validate the fix. One action drives another, impacts another, and makes another come to fruition. Without knowing the problem, you cannot reproduce it, without reproducing it you cannot test it. You need one to do the other, otherwise you are not validating anything.

March 10, 2025

Greg Thomas

The API Does It All

If you can’t do it through the app, there is probably an API that will you do it or a background process. And although this is great, this begs the question – why can’t you do it through the app itself? Why is it restricted?  What was the reasoning? And if you’re now doing it through the API, why do you then need the app?  What is it giving you? Give your App the same power your API does – not everyone is a developer, they bought your app to use it – not to build a solution around it.

March 8, 2025

Greg Thomas

Old Licensing

When your company is new, your licensing model is simple and perhaps even non-existent. “Want our product, please take it, and thanks for using it.” “Want to use it for your team?  Here’s a team license.” “Want to use it for this building?  Here’s a site license.” Simple, achieves the goal. You might not need a license today, but if your customers need to hire a licensing expert to understand what they need to buy – you’ve lost the narrative. Keep it simple, know what you want it to look like in 5 years, whether it’s free today or paid

March 5, 2025

Greg Thomas

Deploying Parallel Software

Upgrades used to control Software Delivery. How well do you upgrade from one version to the other, do you run them side-by-side, etc, etc? When we deployed client/server the big separator is that they were ALWAYS distinct. Now we live in a world where we can “toggle” between the old and new, bringing about its own challenges. If you’re building software that toggles between feature sets there are a few scenarios you should always be aware of; Make sure one setting doesn’t bleed into the other. Keep them independent. If you’re introducing the toggling to get feedback, ask for it,