Do you recognize this early logo from Amazon.com? Future Now has a great article detailing how Amazon evolved their “add to shopping cart” implementation. From reviewing this summary of the evolution of one feature, we can see that Amazon decided there was value in reinvention. The improved the way their product did something over time. Have you?
Continuous Improvement
Software developers understand the value of continuous improvement. It is a core tenet of agile development – as you do more, refactor what you’ve done so that it is better. Some people who promote agile explain that refactoring is a barrier against spaghetti code and broken windows. That is certainly true, but there’s also merit in simply making the product better.
The key is to define “better.” Refactoring as part of implementing something new comes from a simple idea – “elegance” in design includes an analysis of how well the code solves the problems it is being asked to solve. When you add new functionality, you redefine the context by which you analyze. When you extend your code base in unanticipated directions, you are likely to be reducing the elegance of your solution. So you refactor, to make sure your design is elegant given the new context for analysis.
One of the development teams we’re working with right now is proposing a rewrite of a set of utilities that are part of an enterprise architecture. A small piece in a very large puzzle. Unfortunately, their argument is that “the code is not good.” Instead of looking at their specific situation, we can ask the question – “When is there value in rewriting?”
Value In Rewriting
First, we should define rewriting. Imagine that your software is a “black box.” It accepts inputs, and provides outputs. It does some work or analysis or magic or something inside the black box – you don’t know what. When you feed it an input, it responds with an output. Our definition of rewriting for the purpose of this discussion is that the “black box” view of the product does not change. The same inputs produce the same outputs. Not faster, not prettier, not less buggy, not more scalable, nothing. No (externally) perceivable difference.
In other words, the developers are saying “let me rewrite, instead of writing new code.” New code changes the behavior of the black box – the outputs are better or faster or different, inputs are handled differently, etc. A “noticeable” change. As product managers or analysts, we’ll assume that noticeable and valuable go hand in hand. :)
Newton’s First Law of Software: Software, when unmodified, behaves the same way it always has.
What are valid reasons for changing how it is written?
- Fiat. A corporate mandate may come down, stating that all software will be written in a single language, or will run in a specific environment. These types of mandates are intended to drive economies of scale and reduce costs by inspiring teams to leverage competence and knowledge across multiple products. Microsoft Office and Apple both apply this approach in designing consistent user interfaces to their products. People familiar with one application will be able to be productive with a second application more quickly. So there is potential future benefit here.
- Cost of Change. When a product is being actively modified, there is a cost associated with making those changes. That cost is a function of how hard it is to make those changes. Making the code easier to work with does have value, in that it makes the cost of change lower. There can also be benefits here, but they are probably smaller than the value of doing something new. Until they get big. That may be the genius of refactoring as you implement new functionality. By keeping the code base “always good”, you incur small incremental refactoring costs in the context of implementing new features. The argument is that these small costs immediately pay for the next incremental refactoring due to time saved in adding functionality. It is a positive feedback loop.
It rarely makes sense to just rewrite for the sake of rewriting. If development costs represent 20% of the cost of a solution, then you need to reduce development costs by 5% for every 1% of incremental value (from redesign or new functionality) that you postpone. You can easily show that a 5% reduction in development costs “pays for itself” quickly if you operate your development team as a cost center. You should instead be operating as a profit center.
Value in Redesigning
There can be dramatically more value in redesigning a product. Redesigning is one step up from rewriting. These changes are externally visible. The software still does the same things, only it does them better. Better can mean an improved user experience, higher quality, faster responses, more accurate analyses, higher scalability, etc.
From a requirements perspective, a redesign does not change any of the functional requirements. It changes the non-functional requirements. Since non-functional requirements exist to support specific goals, a change in non-functional requirements reflects a change in value. And value drives prioritization.
You can, and should, prioritize redesigns along with adding functionality. Amazon, as the Future Now article (hat tip to Mary Schmidt’s Idea Pool) indicates, valued the repeated attention to, and redesign of the “add to cart” button on their web page. They were clearly making intentional trade-offs between strategic goals. As an example, with one design, they promoted other corporate initiatives at the expense of conversion rates (turning users/clicks into transactions).
Is Your Product Improving?
Our unscientific perception is that most software product teams are myopically focused on “what else should we do” and are forgetting “what can we do better?” It may be that you’re tackling such a large problem that “more” overwhelms “better.” But you should do the analysis.
