Deliver Better Software, Faster

For me, Deliver Better Software, Faster is a guiding principle, and one I strongly recommend you adopt because it describes what must happen to keep your users happy. In addition (and perhaps more importantly), following it can result in a more enjoyable and interesting career. To see how, let’s examine the three parts of this important idea:

1. Deliver means taking responsibility for more than just writing and debugging code. Despite appearances, you aren’t paid to write code. You’re paid to make it easier for your users to do something they find valuable, and until your code is running in production they won’t benefit from your hard work.

Changing your focus from writing code to delivering software requires understanding the overall process for getting your changes into production and then doing two key things:

• Making sure you aren’t doing things that hinder the process, like guessing the meaning of a vague requirement instead of asking for clarification before implementing it.
• Making sure you are doing things that speed up the process, like writing and running automated tests to show your code meets the acceptance criteria.

2. Better Software is shorthand for two ideas you should already be familiar with: “building the right thing” and “building the thing right”. The first means ensuring that what you’ve written meets all the requirements and acceptance criteria. The second is about writing code that is easily understood by another programmer, so they can successfully fix bugs or add new features.

While this may sound easy to do, especially if you follow a practice like Test-Driven Development (TDD), many teams tend to lean one way or the other:

• Non-programmers might push developers to take short-cuts to deliver new features sooner, with promises to come back and “do it right” later.
• Sometimes programmers who just learned something will try to use it everywhere possible, even if they know a simpler solution would work just as well.

In either case, the balance is lost and the resulting technical debt increases the time needed to deliver value to your users until the balance is regained.

3. Faster refers to both Deliver and Better Software, and could be a challenging goal because people trying to do complicated things quickly tend to make mistakes. To me, the obvious solution includes:

• Using a process like TDD to create automated tests, then regularly running the automated unit, integration, and user acceptance tests to verify the system’s behavior.
• Building and running an automated process that runs all the tests in multiple environments and, assuming they all pass, deploys the code to production.

Both of these processes will be done multiple times and require great attention to detail — just the sort of task a computer does faster and more accurately than a person. That’s good because I have one more recommendation: Deploy changes to production more often, so each deployment has fewer changes and is therefore less likely to have problems, and your users get the benefits of your work sooner.

Adopting Deliver Better Software, Faster as a guiding principle is both challenging and fun. Be aware that it will take time to find and fix all the places that need work, but the rewards are worth it.