Software Development Nirvana vs Hotfixes

The purpose of software development is not actually the development of software. If one could accomplish the same result that software development provides without developing any software, then that is what people would do. The purpose of developing software is to provide value to the user of that software. Ideally, the user could get new value from their software as soon as they realized that they needed it or as soon as somebody discovered something new that could be added that would deliver new value. But in the real world it takes time to deliver something new.

Development Efficiency vs Market Efficiency

The value of any particular feature erodes over time. If you take 2 years to develop a whole bunch of great new features and they were all developed really efficiently, that’s great, but what if the value of most of those features has eroded away during the time it took you to do it? You may have gained development efficiency, but you’ve lost market efficiency. Development efficiency is important because cost needs to be less than revenues or you’ll eventually go out of business. But market efficiency generally trumps development efficiency because revenue is so closely tied to delivery time. That is, the faster you can deliver something that people value, the faster you will get the return on that investment. Equally valuable is failing fast; learning that you are headed in the wrong direction and finding a new and more valuable tact to take.

Look at it this way. Which would you rather do? Option 1: plan to deliver 12 features in a year and “efficiently” deliver them in a year but only 4 of the features are a hit with customers. Option 2: have a flexible plan, make changes all year long, and deliver just 10 features in that same year, but 6 of the features are a hit with customers? Also consider that in option 2 the quality is higher. Hopefully, you picked option 2 and voted for market efficiency over development efficiency.

Software Development Nirvana

Based on this, I would say that software development nirvana would be 1 developer, 1 tester, and 1 user documentation writer producing changes and delivering them as fast as they possibly can. And of course the customer(s) are sending money to the team just as fast as that team delivers the software. I realize you may have questions about quality, architecture, and just how fast a customer can take changes. And of course we will want to be able to replicate what this small team does on a larger scale. Let’s park those thoughts for now and just consider that it is hard to imagine a more effective team than the one described here.

Hotfixes to the Rescue?!

It turns out that there is something that all development teams do that mimics this description of Nirvana. It is something that is done very quickly, gets whatever resources are needed, and is done because it is absolutely the highest value producing activity that the organization can do at the time that it is done. That’s right, a hotfix!

Why do you do a hotfix? Because if you don’t somebody somewhere will be losing a great deal of value. That value may be revenues, customer satisfaction, or something else of value. In any case, you do a hotfix because it produces the most possible value to your organization compared to anything else you could do at that moment. It may not seem like value, but negating a negative value is a positive value.

A good deal of my Agile thinking stems from this one observation: if the process used to resolve a hotfix is the best way to produce the highest value as fast as possible, then why don’t we do that with all of the software we produce all the time? One caveat is that most hotfix processes cut corners in order to go fast, but what if there was a way to do hotfixes without cutting corners? 

Tweet

Read: "One Piece Flow", an intentional version of hotfixes.

Check out our free webinar "Panning for User Story Gold"

Date: March 6th at 1pm ET.

Click here to register 

Description: "Putting User Stories into business value order is a key tennet of Agile, but that's just the first step. There's much more value to be extracted from your user stories using specific story splitting techniques combined with reducing cycle time. By splitting user stories you can separate the gold from the dirt as well as reduce the cost of implementation. This session will cover a variety of methods for splitting user stories and reducing cycle time including the "create/read/update/delete" method, the acceptance test method, the split by value method, frequent grooming, Kanban flow, and software tool support."

Click here to register