Software Rewrites and the Branding Dilemma

At some point most people who work with software have been involved in a major software rewrite. The point in a software product’s lifespan where the project owners decide it is time to revisit the fundamentals of their software and start over. Sometimes this is motivated by a desire to move to a new technology stack, other times it is to address serious architectural flaws that have existed from early days. However, often the ramifications of a software rewrite are not fully understood and can lead to some nasty misunderstandings if not addressed early and often.

When software is being updated it receives a new version number that describes the magnitude of the changes. Major changes may rev the product from version 3.x to version 4.0, while smaller changes might rev only from 3.3 to 3.4. The problem creeps in when dealing with rewrites.

Teamwork When Awesome Inc. decide that their AwesomeWare 3.5 software needs to be rewritten it is likely that the company will see this rewrite as version 4.0 of the software. It is assumed that new features will be introduced in addition to the "engineering need" for a new technology stack. Software rewrites are often costly and new features are promised as a means to soften the blow of the expense of the project. In reality, however, this is not version 4.0 of the software. A software rewrite means delivering version 1.0 of the sequel to the original product. This is where the problem occurs and becomes a hard pill to swallow.

What starts as a difference in the naming/branding of the product will quickly flourish into lengthy discussions about software quality and feature parity. When software is being updated it is understood that the new version will add some new features, refine some existing features, and solve a few bugs. Existing features should not be removed unless specifically requested, and old bugs should certainly not be reintroduced. When software is being updated this is very achievable with an appropriate development process. However, when software is being rewritten these premises rarely hold true.

Software rewrites involve revisiting fundamental assumptions about the way the product works. Every department wants the opportunity to revisit the decisions they made when the first version of the product was being developed. Database architects want to fix the flaws in their schema that have crept in over the years. Product managers want to fix workflows that don’t quite work correctly, and developers will be rewriting almost every line of code from scratch. This creates a monster project that is larger in scope than the first 1.0 of the software but with much loftier expectations.

pointing-the-blame All of this leads to the development of a new product that is supposed to do everything the old product did but better and cooler and in newer technology. In reality this version 1.0 software will have all of the blemishes and warts of a first version release. Bugs that haven’t been seen since the "early years" will start to manifest themselves again. Features that were hiding in dark corners of the original product will be forgotten or just not work the same way. The product itself will change and taken on a whole new tempo. All of this comes with the benefits of having fixed fundamental architectural flaws in all layers of the product as well as having adopted a new technology stack. However, those benefits are of most visibility to technical departments and that value is hard to translate to other areas of the business.

From a branding perspective this should be AwesomeWare version 4.0 not AwesomeWare 2 version 1.0. As a result it often retains the version 4.0 branding and all of the assumptions that go along with it, for stakeholders and users alike. Somewhere in that transition it is lost that this is a version 1.0 rookie that has only been around for a few months, not a six year veteran that has been battle hardened over the years. Bug counts will spike, features from the version 3.x product will be lost, and fingers will start pointing in all directions looking for who to blame.

The reality is that performing a software rewrite the same undertaking as writing new software, no matter how much intellectual property and prior lessons learned are included. New software is new software and that means new bugs, new (and differently imagined) features, and a whole new journey towards refining what is produced into a solid product.

This isn’t to say that software rewrites aren’t sometimes the right option. Technical debt accumulates as a result of decisions made to meet business needs. Technology stacks age as better platforms and frameworks are developed. Rewriting large parts of the software is often the only means to address these issues. However, the assumption with most software from a marketing perspective is that it is a stable platform from which all new versions will be additive and progressively more stable.

office space It is important that staff in charge of technical communications make the reality of the software known to all levels of the business and to address the differences in understanding of what software versioning means. When a rewrite is undertaken it is important that all parties understand the technical reality of the situation and what can be expected as a result. Leaning on technical staff to "make it do everything the old product did but better" is not a realistic expectation and will not lead to a successful project. Instead, communicate the ramifications of decisions, and communicate them often. There will always be a difference in understanding of what a new software version means, but going into it with full communication can help lessen the impact of that difference earlier in the lifecycle and hopefully avoid some big surprises later on.

This entry was posted in Quality Assurance, Uncategorized and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *