Six stories as code rewrote from scratch
A new look at the eternal question: should the application be rewritten from scratch or is it “the worst strategic mistake a software developer can make”? It turns out that when working with a mature code base there are more than two possible answers.
Almost two decades ago, Joel Spolsky arranged Netscape for what she rewrote the code base of the browser in his epochal essay "What you can never do . " He concluded that functioning software absolutely should never be rewritten from scratch . He had two main arguments:
')
For many, Joel’s conclusions have become dogma; at one time they had a great influence on me. But in subsequent years, I realized that in some circumstances, there is still a sense of a complete rework of the product. For example:
Of course, in fact, much depends on the circumstances. Yes, sometimes it makes sense to gradually refactor obsolete code. And yes, sometimes it makes sense to throw everything away and start over.
But this is not the only choice . Let's take a look at six stories and see what lessons can be learned.
Browser code rewritten three times from scratch
Netscape's catastrophic transition from 5.0 to 6.0 was the reason for the aforementioned article by Joel Spolsky and convinced many that it should never be done this way.
Netscape Navigator was released in 1994, in the early years of the commercial Internet. In less than two years, the company opened the dot-com era, conducting an IPO of $ 3 billion.
Netscape’s first serious competitor was Microsoft Internet Explorer, which was released in 1996.
In early 1998, Netscape was still the leading browser, but with great difficulty. Netscape was a commercial program that sold for $ 49, and Microsoft distributed IE for free and delivered as the default browser in Windows.
After the release of Netscape 4.0, the company announced that the next version will be free and will be developed by the open source community created and sponsored by Mozilla. For its time, it was essentially an unprecedented step, and Netscape gained many supporters for such a bold decision. But in reality, this “community” actually did not materialize. Jamie Zavinsky, one of the first browser developers, explains :
The team concluded that the developers were not interested in the project, including because of the mess in the code base:
Thus, a year later, the group decided to abandon 5.0 without releasing the release, and began developing version 6.0 from scratch.
Netscape 6.0 preparation took two full years; and even after all this, it was clear that the browser is raw. According to David Pogue, a New York Times columnist , the browser was launched for a full minute (!) And absorbed RAM. He lacked a number of simple usability functions that were in previous versions:
But it almost did not matter, because in three years that Netscape stood still, Internet Explorer captured the rest of the market share:
When the browser redesigned, Netscape quickly lost ground to Microsoft Internet Explorer. The new browser came out three years later, it was buggy and slow; and the market share of Netscape, meanwhile, has shrunk to almost zero (adapted from Wikipedia )
In 1999, when the browser was being redesigned at full speed, AOL acquired Netscape for $ 10 billion. Just two years after Netscape 6.0 was released, the Netscape division at AOL was liquidated.
Mozilla, the open source community created by Netscape, will continue to exist and release the Firefox browser in 2002 — another project from scratch. Firefox was able to return some of the users who went to Microsoft.
But Netscape as a business died (Microsoft will bury the remains of Netscape intellectual property as a result of the 2012 AOL deal).
Having won this battle, Microsoft refused to invest in browser technology. Internet Explorer 6.0 was released in 2001 and has not been updated for five years . Some consider this a deliberate attempt to block the promotion of the Internet as an application platform.
Some believe that rewriting from scratch did not become a disaster. In the end, thanks to this, the Gecko engine and Firefox browser finally appeared.
But we all had to endure years of stagnation in web technologies under the endless, suffocating monopoly of IE6 , while we were looking forward to a new browser that breathed life into the industry. And the end of the era of IE6 put not Firefox, but Google Chrome.
In any case, it's not about how the project affected the Internet. It's about the result for the company. Netscape’s death cannot be completely attributed to these reasons: the court agreed that Microsoft intentionally abused its monopoly. But of course, the decision to rewrite everything from scratch became an important factor and led to the final result: the destruction of a company worth billions of dollars and thousands of layoffs. Therefore, I agree with Joel that the net consequences of this decision were disastrous .
In the early 2000s, a Chicago web design studio called 37signals became famous for an influential and often controversial blog run by the founders Jason Fried and DHH .
When I first started working on web design, they caught my attention with a series of articles with examples of wrong designs and options for how to remake them, for sites such as Google and PayPal. The project was called 37better .
The redesign of the 37signals FedEx delivery form (above) is still better than real design , almost two decades later
The company had a project management system for internal use , which they released in 2004 as a SaaS service called Basecamp .
At that time, SaaS was still a novelty. Project management tools were sold in boxes with four-digit price tags and weighty guides. All of them worked on the concept of modeling critical paths and drew complex Gant charts. Basecamp sold for $ 50 a month and became a breath of fresh air with its super-simple interface and communication orientation.
Fast forward a few years ahead, Basecamp has half a million happy users, payments arrive every month, but Jason and David are getting worried.
A few years ago, David told this story at the Business of Software conference. He admitted that he was under the influence of Joel Spolsky and believed that rewriting the software would kill the company. In addition, there was a certain element of complacency and self-righteousness due to the popularity of the Agile movement:
However, after the "seven fat years" the company found itself in a quandary - and the problem had nothing to do with technical debt .
It all started with the fact that the guys noticed a lack of enthusiasm. Not only did the lack of motivation to work on the flagship product, they themselves did not particularly use their program.
They had a lot of ideas on how to make the product fundamentally better, but any change would break the usual workflow of hundreds of thousands of Basecamp users. The problem was not in a complex code base, but in users.
Because of the desire to please existing customers, the product stopped developing, which prevented the attraction of new users. This did not threaten the business directly, but created a long-term threat. DHH metaphorically compared the situation with a leaky bucket:
Part of the problem is that you constantly listen to current customers, but do not hear future ones:
Developers began to consider a profitable product as a pair of gold handcuffs:
Spoiler: Basecamp rewrote from scratch, and it turned out great. It took about a year, and immediately after the release of Basecamp 2, the number of new registrations doubled.
I think they did two main things.
First, they did not try to remake the old product - because first of all they wanted to implement new ideas about how to approach the solution of the problems that the old product solved.
Thus, they presented Basecamp 2 as a completely new product, backward compatible with Basecamp Classic without any guarantees. Many new things have appeared, something has disappeared altogether, and much has completely changed.
This decision gave a certain degree of freedom. Freedom is motivating, and motivated people work better.
The lack of need to support each of the uses of the original product also helped. For example, the original Basecamp allowed to post documents on its own FTP server. The developers have removed this and other similar functions that previously made sense, and now have become marginal. Such a reduction in unnecessary functionality allowed to bring a new product to the market within a reasonable time.
But what about the hundreds of thousands of existing users who are taking their favorite toy? This brings us to the second interesting thing the developers did: they kept the old product .
David notably explored the term "sunset software":
He noted that forcing people to pack and move is the “worst strategic mistake” because you make all regular customers decide to continue using your software or switch to something else.
David compared the Basecamp Classic with the Leica M3: the camera has not been manufactured since 1967, but Leica promises to maintain and repair it until the end of its days (photo: Dnalor 01 )
Instead, Basecamp pledged to “respect its heritage” : they simplified the update to the new version, but did not demand to leave Basecamp Classic. In addition, they pledged to support Basecamp Classic forever.
The joke is that four years later they did it again: in 2015, Basecamp 3 was released, again rewritten from scratch, with some new features and without some old ones, and again a lot has changed. As before, users of older versions can easily make an upgrade. But if they want, they can continue to use Basecamp Classic or Basecamp 2 "until the end of the Internet."
Personally, this model seems to me really inspiring.
Each revamp allowed Basecamp to look back and redo the product based on experience. For users, this is a win-win game: conservatives retain their toy; and innovators who are faced with the limitations of the system receive a new and, I hope, more thoughtful application.
Of course, support for multiple versions has a price for an infinitely long time; but as david says:
Note: hipster badge
Microsoft made VS Code to reach developers on other platforms.
You have to remember that for a long time Microsoft offered “all or nothing”. If you used Visual Studio, you definitely worked in .NET, and vice versa. This divided the software community into two large, largely mutually exclusive camps - to the detriment of all.
The situation began to change even in the years of Steve Ballmer: remember how loud the ASP.NET developers' decision not to invent jQuery has become!
One of the main tasks of the CEO Satya Nadella was an appeal to the developers outside their "fenced garden".
But there was a problem. Here is what Julia Lewson, vice-president of Visual Studio says in this release of The Changelog podcast :
Visual Studio is a heavy product in every sense: only installation can take more than half an hour. It supports a wide range of complex use cases relied on by corporate customers. Thus, there was no point in taking Visual Studio as a starting point and adding features to a new project on other platforms. And obviously, the idea of releasing Visual Studio for Mac or Linux was not particularly supported.
Therefore, Microsoft started from scratch, with no guarantees of backward compatibility.
In fact, not entirely from scratch: Microsoft already had some important parts, such as the browser editor Monaco. And since VS Code is a Node.js application (written in Typescript and running on Electron), they used the rich JavaScript ecosystem resources.
Open Source VS Code, easy, fast, extensible — surprisingly for a Microsoft product — has become a fashionable programming tool for advanced youth.
VS Code became the main editor for JS hipsters (chart from State of JavaScript Survey report , 2018 )
Both products are still being actively developed, and there is no indication that Microsoft intends to close Visual Studio.
Unlike Netscape, Microsoft really managed to create an active open source community around VS Code. It has increased the efforts of developers to improve the product.
Of all the open source projects, Visual Studio Code ranks 13th in terms of stars on GitHub - coincidentally, just below Linux!
Of course, not every company can afford to lay out its main product for free access. But if open source is part of your development strategy, it makes sense to compare the stories of Microsoft and Netscape - and find out what Microsoft did differently for its community to flourish.
Another important factor: Microsoft has provided VS Code with a quality extensibility model , with the result that the community has already written about 10,000 extensions.
One of the latest conclusions from the history of VS Code is that over the past few years everything has changed dramatically: it is easier to create prototypes and software than ever before .
Despite the groans about the complexity of the modern toolkit , the JavaScript ecosystem has in the past few years turned into a veritable paradise of open source modules. In this regard, it is now historically unprecedented time.
Note: sunset icon
Inbox for Gmail was originally presented as an alternative minimalistic Gmail UX, “with a focus on what really matters.” He never tried to match the functionality of the original Gmail, and also introduced new features: thematic groups (bundles), pinned letters and deferred messages.
Some users, including me, enthusiastically accepted the Inbox. I always thought that Inbox is a demo version of what Gmail will eventually become, so I put up with the absence of some of the nuances of Gmail, expecting that they would eventually get to Inbox.
Inbox and Gmail worked on the same backend. In essence, these are just different user interfaces for the same service, and you could switch back and forth at will. This had its advantages and disadvantages: if there was no function in the Inbox (say, a vacation answering machine), you could always return to Gmail and configure what you need, although switching back and forth seemed strange.
However, after a while, Inbox stopped improving - it became clear that Google no longer invested resources in it. Naturally, four years after launch, Google announced the decline of the Inbox .
Like everyone else, at first I was angry about such a decision. But after spending a bit of time with the latest version of Gmail, I found that many of my favorite Inbox features were transferred to the original product : smart answer, hover actions, embedded attachments, and images. A few Gmail mailboxes are quite tolerably replaced by themed Inbox groups.
But not all of Inbox have been transferred to Gmail: for example, people are so used to the “pause mode” (snoozing) that they literally physically suffer without it.
Inbox gave Gmail developers the opportunity to experiment with features without disrupting the workflow of the vast majority of users.
However, serving both versions on the same backend , Gmail has put severe restrictions on innovation .
Once again, Google has been widely criticized for closing the popular service. Of course, Google is constantly closing its projects , so nothing unexpected.
But in this case, the initial attitude of Google to Inbox led to believe that we have a demo version of the future of Gmail. As DHH would say, the sunset came out ugly: many people found it unpleasant to return to the old product and lose their innovative Inbox workflows.
I think for many people the transition would be much easier if all of its functions were integrated into Gmail before closing the Inbox.
Note: badges of sad decline and "money, money, money"
FogBugz is a particularly interesting case, because it is a product of Joel Spolsky himself: he gives an idea of how the principle of “never rewrite” interferes with real life.
Before Jira and GitHub Issues, there was a web-based ticket tracking system called FogBugz. Released in 2000, this system was the first product of the new company Fog Creek Software, which Joel founded with Michael Prior. And for more than a decade, FogBugz remained their flagship product. Initially, it was sold only as a boxed version for installation on its own servers, but later came the option of SaaS with payment by subscription.
FogBugz has become very popular, especially among developers who, in my example, read Joel’s blog and took his advice to heart. My company used the system for many years, it was a great product for its time.
FogBugz was originally written on classic ASP, which worked on Windows servers. When ASP.NET came out, Joel explained why he was in no hurry to update .
To install FogBugz on Linux servers, a company trainee wrote the Thistle compiler to convert classic ASP to PHP. By 2006, Thistle had grown into a proprietary programming language called Wasabi, which is compiled into ASP, PHP, and client-side JavaScript.
Nowadays, developing your own proprietary programming language and compiler is, let's say, an eccentric choice. So it is interesting to see how it all happened.
At some point, Joel mentioned Wasabi in a blog post. Some thought it was a joke, so he explained that it was not a joke . A fellow blogger Jeff Atwood's head exploded from this news:
Joel insisted that the decision made sense from a business point of view. Of course, theoretically, it’s not worthwhile to invent your own language, but if you evaluate every small step towards such a decision, given the technological context and the code base, everything seemed logical.
Reflecting on Wasabi in a meaningful essay entitled “Technical Debt and Wind Search,” former Fog Creek engineer Ted Unangst compares the process to traveling without a map:
In any case, explains Jacob Krall, another former developer of Fog Creek, the decision sacrificed tomorrow's maintainability for the sake of today's development speed. And by 2010, steel comes bills for this debt.
By that time, FogBugz was already ten years old: it was a mature and stable product. As a side project, Joel launched Stack Overflow with Jeff Atwood (obviously, Jeff’s blown-up head had healed by then).
FogBugz was gradually getting older. Although the bug tracker market remained fragmented, Jira from Atlassian, which came out a couple of years after FogBugz, came to the fore. It has become the default choice, especially for large corporate users.
This particular inflection point in FogBugz history is really interesting to look at. Like Basecamp, they had a profitable, mature product. Yes, not so fashionable, and maybe it was not very interesting to work on it. Good or bad, but it has absorbed many years of technological change and new ideas on how to solve one specific problem: tracking of bugs.
Of course, there was a Basecamp option: taking into account all the experience, take and rewrite FogBugz from scratch. I suppose this idea has not gone too far, because we remember: “what can never be done”, “worst strategic mistake” and so on and so forth.
I recently came across an article in 2009 that Joel wrote for Inc. Magazine. His author’s column under the heading “Does slow growth mean slow death?” The tone is completely different from the usual self-assured bombast: it sounds introspective, uncertain, filled with doubts. Joel is worried about the rapid growth of Atlassian, reasons whether there is room on the market for several players.
He decides to do two things. First, add all the features in FogBugz :
Secondly, create a corporate sales department . Joel admits that he is not strong here, and finds this task unpleasant.
I do not know how these measures worked. The last time Joel mentioned FogBugz was in his blog in May 2010 , briefly announcing a new version.
And this is what happened :
Therefore, they were divided into two teams, each of which made a prototype of a new product. The winning idea was created in the spirit of kanban board — a real offline board that is often used in software development projects: it usually looks like notes distributed across columns on the board.
Joel introduced this program as a management tool at a higher level than FogBugz:
When creating Trello, Fog Creek developers got a chance to use modern technologies:
Trello supported plugins from the start, so third-party developers started helping:
Programmers, of course, immediately understood the benefits of Trello, But there was nothing specific to the development of software in the tool. Joel described Trello as a useful tool for "everything where you want to keep a list of lists with other people ." Soon Trello began to be used for organizing everything in a row: from weekly dinners to weddings and dog-shelters .
While FogBugz was a vertical product - focused on a specific market niche - Trello was a horizontal product suitable for anything. Joel considers the “horizontal movement” of Fog Creek to be correct at that stage:
To quickly scale to a very large number of users, Trello was initially offered for free. Later introduced a business plan .
In 2014, Trello was assigned to an independent company. Three years later, with more than 17 million users, it was sold for $ 425 million . Ironically, the buyer was Atlassian, the old arch-enemy of Fog Creek.
Fog Creek continued to develop another new product, a co-programming environment called HyperDev , which was later renamed GoMix and then Glitch .
At the same time, the FogBugz system was mired in obscurity. In 2017, someone decided that FogBugz was a foolish name in general, and engineering efforts went to rebrand the product as Manuscript . A year later - just a few months ago - Fog Creek sold the product to a small company DevFactory , which immediately returned the name FogBugz .
Under the direction of CEO Anila Desh, Fog Creek became a one-product company and changed its name to Glitch .
I have a lot of thoughts on this.
The key to understanding the story is that Fog Creek has always cared not so much about bug tracking as it is about empowering programmers — starting with their own:
Given this “formula,” you can make a logical and encouraging conclusion: Fog Creek has built a business around the happiness of developers. This was reflected both in the company's products and in its internal “operating system” . The first product, a bug tracker, served as the basis for launching a new product that solved a similar problem in a more abstract way.
From the words of Joel, it seems that the story of Trello is a search not so much of a new business, as there are opportunities to support the motivation and involvement of Fog Creek developers . A product worth half a billion dollars was just a pleasant side effect.
However, a little sad how it ended for FogBugz. I do not think that the developers of Fog Creek were particularly happy in the last days before the sale.
It is clear that there were bigger and bigger projects: Stack Overflow, Trello and Glitch - each one is much more useful and more valuable than FogBugz; and it is impossible for one person to keep track of everything. Therefore, I cannot blame anyone, in particular, for the loss of interest in FogBugz with a 20-year code base and strong competition in the market. But loyal users at least found a good home and did not receive a “sunset” type medicine!
However, the sentimental part of me would prefer to more worthily “honor the heritage” of all those involved in the creation and use of this product over the past years.
Note: secret operation icon
The article has grown more than I expected, but I can not leave this story aside. Hold on, there will be an unexpected turn.
In the early 2000s, Mike McDerment had a small design firm. He decided that accounting software was too complicated, so he used Word and Excel for billing.
Everything worked fine to one case :
Mike is a designer, not a programmer, but he and two co-founders managed to assemble a tool that is good enough for several people to pay $ 10 a month to use it. It took almost four years to get the business out of the basement of the parental home.
By the 10th anniversary of the program (sounds familiar?) Freshbooks has become a profitable company with more than 10 million users and 300 employees.
But there was one problem. By the time the company managed to hire "real" programmers, they had a million lines of "founder code". An external analyst reviewed the code base and came to the conclusion:
More importantly, in the existing product it was impossible to implement the existing ideas:
MacDerment is familiar with the conventional wisdom that you cannot rewrite the system from scratch:
Thus, they made several attempts to clear the mess without rewriting the system from scratch; but “replacing tires on the go” proved impossible.
MacDermenta visited the idea of secretly creating the “competitor” FreshBooks.
He founded a completely new company in Delaware called BillSpring. She had her own website, brand and logo. Trying not to link the two companies, he instructed the external lawyer to develop new documents for her.
The development team implemented the “Lean UX: Designing Great Products with Flexible Teams” flexible development practices based on the book by Jeff Gotelf and Josh Seyden : Scrum teams and weekly iterations with feedback from real customers. MacDerment asked them to behave like a startup, and perceive it as a venture investor:
The team managed to release MVP a few days before the deadline. They bought AdWords keywords to drive traffic, offered users free accounts for the first year. Soon, customers appeared - and fast iteration cycles of the real product began.
At the end of the first year, BillSpring began to charge. At some point, a new product received an unexpected quality rating :
Soon, they lifted the veil of secrecy and told BillSpring customers that this was a product of FreshBooks, and also notified existing customers of FreshBooks that the new version would be released soon.
Gradually, the clients of the “classic” FreshBooks made a new version, but they could always return to the old version if they wanted.
The secret project FreshBooks did not come cheap: according to McDerment, they spent $ 7 million on it. However, after more than a decade of growth exclusively on their own resources, they raised $ 30 million in venture capital, so there was money. Not everyone can afford it.
Forbes estimated FreshBooks revenue in 2013 at $ 20 million. After completing the upgrade in 2017, they earned $ 50 million. It is not known how much came from the new product, but writing a system from scratch clearly did not slow down the company's growth.
MacDerment says that the process of developing and implementing new features has become faster and easier. More importantly, they now have a product in their hands that implements the best ideas. With this is not scary to look to the future.
In addition, the experience gained has changed the culture of the company - in a good way. When they pretended to be a startup, they learned how to work as a startup. Practices Lean UX spread to the entire team of developers. Customers are actively involved in developing new features.
FreshBooks went to extraordinary measures to protect itself from potential problems: introducing innovations under the fake brand, developers could completely rethink the program and take on big risks. Even in the worst case, they will not damage the existing brand.
All this seems a bit extreme. Perhaps such measures were not necessary. But this is a reminder of how serious the stakes are.
It is generally accepted that it is better to avoid rewriting the program from scratch , and if possible to make gradual improvements. For the most part, I agree with that.
But the advice suggests that in the end we will get the original product plus a set of new features.
But what if you want to remove the functionality? Or implement some option completely different ? What to do if with ideas came a fundamentally new approach?
My conclusion from these stories is: as soon as you realize that the current version is very different from the imaginary ideal , then the new version should be released not as a replacement, but in parallel with the current one .
When thoughts arise to rewrite everything from scratch, it may be worth asking other questions. Maybe create your own competitor? If my product is FogBugz, then what will be my Trello? If this is Visual Studio, what will my VS Code look like?
If we compare Spolsky 's article about Netscape and the DHH post about Basecamp, then they agree on one thing: Legacy has value.
The good news is that you don’t need to throw away this value in order to innovate.
“The source code seemed to rust !” - Joel Spolsky
Almost two decades ago, Joel Spolsky arranged Netscape for what she rewrote the code base of the browser in his epochal essay "What you can never do . " He concluded that functioning software absolutely should never be rewritten from scratch . He had two main arguments:
')
- The garbage parts of the codebase often include hard-earned knowledge of border situations and strange errors.
- Complete rework is a long-term enterprise that distracts from the improvement of the existing product, which gives trumps to competitors.
For many, Joel’s conclusions have become dogma; at one time they had a great influence on me. But in subsequent years, I realized that in some circumstances, there is still a sense of a complete rework of the product. For example:
- Sometimes an outdated code base is really not recoverable, so even a simple upgrade requires cascading changes to other parts of the code.
- Original technological solutions may prevent you from making the necessary improvements.
- Or, the original technology may become obsolete, which makes it difficult (or too expensive) to hire skilled developers.
Of course, in fact, much depends on the circumstances. Yes, sometimes it makes sense to gradually refactor obsolete code. And yes, sometimes it makes sense to throw everything away and start over.
But this is not the only choice . Let's take a look at six stories and see what lessons can be learned.
1. Netscape
Browser code rewritten three times from scratch
Netscape's catastrophic transition from 5.0 to 6.0 was the reason for the aforementioned article by Joel Spolsky and convinced many that it should never be done this way.
Netscape Navigator was released in 1994, in the early years of the commercial Internet. In less than two years, the company opened the dot-com era, conducting an IPO of $ 3 billion.
Netscape’s first serious competitor was Microsoft Internet Explorer, which was released in 1996.
In early 1998, Netscape was still the leading browser, but with great difficulty. Netscape was a commercial program that sold for $ 49, and Microsoft distributed IE for free and delivered as the default browser in Windows.
After the release of Netscape 4.0, the company announced that the next version will be free and will be developed by the open source community created and sponsored by Mozilla. For its time, it was essentially an unprecedented step, and Netscape gained many supporters for such a bold decision. But in reality, this “community” actually did not materialize. Jamie Zavinsky, one of the first browser developers, explains :
The truth is that the participants in the Mozilla project included about a hundred full-time Netscape developers and about thirty freelancers, so the project was still fully owned by Netscape.
The team concluded that the developers were not interested in the project, including because of the mess in the code base:
The code was too complicated and confused to change, so people did not make their contribution ... That's why we switched to a new engine. A cleaner, fresher code base that is easier to understand and join development.
From scratch
Thus, a year later, the group decided to abandon 5.0 without releasing the release, and began developing version 6.0 from scratch.
Netscape 6.0 preparation took two full years; and even after all this, it was clear that the browser is raw. According to David Pogue, a New York Times columnist , the browser was launched for a full minute (!) And absorbed RAM. He lacked a number of simple usability functions that were in previous versions:
The print preview function has disappeared, as well as the ability to drag the site address icon directly into the bookmarks menu. Also, you can not copy or paste the web address into the address bar by right-clicking it. And each time at the beginning of work, you have to change the window size: Navigator does not remember the previous state. But the most unpleasant drawback is that you cannot select the entire address bar with one click of the mouse.
But it almost did not matter, because in three years that Netscape stood still, Internet Explorer captured the rest of the market share:
When the browser redesigned, Netscape quickly lost ground to Microsoft Internet Explorer. The new browser came out three years later, it was buggy and slow; and the market share of Netscape, meanwhile, has shrunk to almost zero (adapted from Wikipedia )
In 1999, when the browser was being redesigned at full speed, AOL acquired Netscape for $ 10 billion. Just two years after Netscape 6.0 was released, the Netscape division at AOL was liquidated.
Mozilla, the open source community created by Netscape, will continue to exist and release the Firefox browser in 2002 — another project from scratch. Firefox was able to return some of the users who went to Microsoft.
But Netscape as a business died (Microsoft will bury the remains of Netscape intellectual property as a result of the 2012 AOL deal).
Having won this battle, Microsoft refused to invest in browser technology. Internet Explorer 6.0 was released in 2001 and has not been updated for five years . Some consider this a deliberate attempt to block the promotion of the Internet as an application platform.
findings
Some believe that rewriting from scratch did not become a disaster. In the end, thanks to this, the Gecko engine and Firefox browser finally appeared.
But we all had to endure years of stagnation in web technologies under the endless, suffocating monopoly of IE6 , while we were looking forward to a new browser that breathed life into the industry. And the end of the era of IE6 put not Firefox, but Google Chrome.
In any case, it's not about how the project affected the Internet. It's about the result for the company. Netscape’s death cannot be completely attributed to these reasons: the court agreed that Microsoft intentionally abused its monopoly. But of course, the decision to rewrite everything from scratch became an important factor and led to the final result: the destruction of a company worth billions of dollars and thousands of layoffs. Therefore, I agree with Joel that the net consequences of this decision were disastrous .
2. Basecamp
In the early 2000s, a Chicago web design studio called 37signals became famous for an influential and often controversial blog run by the founders Jason Fried and DHH .
When I first started working on web design, they caught my attention with a series of articles with examples of wrong designs and options for how to remake them, for sites such as Google and PayPal. The project was called 37better .
The redesign of the 37signals FedEx delivery form (above) is still better than real design , almost two decades later
The company had a project management system for internal use , which they released in 2004 as a SaaS service called Basecamp .
At that time, SaaS was still a novelty. Project management tools were sold in boxes with four-digit price tags and weighty guides. All of them worked on the concept of modeling critical paths and drew complex Gant charts. Basecamp sold for $ 50 a month and became a breath of fresh air with its super-simple interface and communication orientation.
Fast forward a few years ahead, Basecamp has half a million happy users, payments arrive every month, but Jason and David are getting worried.
A few years ago, David told this story at the Business of Software conference. He admitted that he was under the influence of Joel Spolsky and believed that rewriting the software would kill the company. In addition, there was a certain element of complacency and self-righteousness due to the popularity of the Agile movement:
[Me] was completely absorbed by the idea of transcendental software ... An infinitely plastic code. An infinitely valuable legacy. You can change anything, rewrite any program, any code ... If the software is difficult to change, it's your own fault. You are a bad programmer, which means you need to improve.
However, after the "seven fat years" the company found itself in a quandary - and the problem had nothing to do with technical debt .
Gold handcuffs
It all started with the fact that the guys noticed a lack of enthusiasm. Not only did the lack of motivation to work on the flagship product, they themselves did not particularly use their program.
They had a lot of ideas on how to make the product fundamentally better, but any change would break the usual workflow of hundreds of thousands of Basecamp users. The problem was not in a complex code base, but in users.
Because of the desire to please existing customers, the product stopped developing, which prevented the attraction of new users. This did not threaten the business directly, but created a long-term threat. DHH metaphorically compared the situation with a leaky bucket:
You can plug all the holes, correct all the errors, update all the functions that existing customers complain about - but some of the water always flows out. Clients leave work and leave software, even if they [like] it. You can be misleading: “Hey, the bucket is more than half full. It's just a little hole, just a little leak, it's completely natural. " But, if the situation continues, the bucket is completely empty.
Part of the problem is that you constantly listen to current customers, but do not hear future ones:
People who visited the Basecamp page in 2011 and refused to buy the product because it did not suit them anymore: how do you think, how often did we listen to their opinions? Never. We listened only to a wide base of existing customers who really wanted us to just continue to plug these little holes.
Developers began to consider a profitable product as a pair of gold handcuffs:
The main thing is to make sure that all current users are happy. Money comes every month, a new check, a new check, a new check. Fine. But then stretch your arms and admit: "Everything, I will never change my software again."
Spoiler: Basecamp rewrote from scratch, and it turned out great. It took about a year, and immediately after the release of Basecamp 2, the number of new registrations doubled.
I think they did two main things.
First, they did not try to remake the old product - because first of all they wanted to implement new ideas about how to approach the solution of the problems that the old product solved.
Are we so arrogant to consider the ideas of 2003 still the best ideas in 2011? Yes, I was accused of arrogance, but all the steam came out in 2008.
Thus, they presented Basecamp 2 as a completely new product, backward compatible with Basecamp Classic without any guarantees. Many new things have appeared, something has disappeared altogether, and much has completely changed.
This decision gave a certain degree of freedom. Freedom is motivating, and motivated people work better.
The lack of need to support each of the uses of the original product also helped. For example, the original Basecamp allowed to post documents on its own FTP server. The developers have removed this and other similar functions that previously made sense, and now have become marginal. Such a reduction in unnecessary functionality allowed to bring a new product to the market within a reasonable time.
Sunset is considered harmful
But what about the hundreds of thousands of existing users who are taking their favorite toy? This brings us to the second interesting thing the developers did: they kept the old product .
David notably explored the term "sunset software":
Someone somewhere invented a beautiful euphemism called "sunset" ... Call the destruction of software "sunset" ... Like all users are lying on the beach - and with emotion they watch their information disappear. It's fine!
The only people who believe in the "sunset" are those who call it that. No user who has ever really passed through the sunset period returns and says, “Oh, that was beautiful.” They come back and say, “Damn! I have invested years of work here! .. And now you are going to roll me ?! ”
He noted that forcing people to pack and move is the “worst strategic mistake” because you make all regular customers decide to continue using your software or switch to something else.
Do I really need a basecamp? If you still have to transfer all the junk, maybe move it somewhere else. If you need to pack things in boxes and load them into a truck, I can just ship this truck through the whole city. Not such a big problem. The big problem is pack all manatki. But where to move, again to Basecamp or to another place, this is already a minor issue.
David compared the Basecamp Classic with the Leica M3: the camera has not been manufactured since 1967, but Leica promises to maintain and repair it until the end of its days (photo: Dnalor 01 )
Instead, Basecamp pledged to “respect its heritage” : they simplified the update to the new version, but did not demand to leave Basecamp Classic. In addition, they pledged to support Basecamp Classic forever.
The joke is that four years later they did it again: in 2015, Basecamp 3 was released, again rewritten from scratch, with some new features and without some old ones, and again a lot has changed. As before, users of older versions can easily make an upgrade. But if they want, they can continue to use Basecamp Classic or Basecamp 2 "until the end of the Internet."
Basecamp 3 is not going to roll up anything. Not the current version, not the classic, original version of Basecamp. Do any of them work well for you? Cool! Please continue to use it until the end of the Internet! We will ensure that the programs are fast, secure and always available.
But there is a lot of "but." Isn't that expensive? Does multiple versions require a lot of effort? What about security? How about outdated codebases? What can I say. We just care about customers, even if they don’t want to be updated on our schedule.
findings
Personally, this model seems to me really inspiring.
Each revamp allowed Basecamp to look back and redo the product based on experience. For users, this is a win-win game: conservatives retain their toy; and innovators who are faced with the limitations of the system receive a new and, I hope, more thoughtful application.
Of course, support for multiple versions has a price for an infinitely long time; but as david says:
It is not free. Of course not. This is a valuable product and of course, support is not free. But it is worth it.
3. Visual Studio & VS Code
Note: hipster badge
Microsoft made VS Code to reach developers on other platforms.
You have to remember that for a long time Microsoft offered “all or nothing”. If you used Visual Studio, you definitely worked in .NET, and vice versa. This divided the software community into two large, largely mutually exclusive camps - to the detriment of all.
Appeal to cool guys
The situation began to change even in the years of Steve Ballmer: remember how loud the ASP.NET developers' decision not to invent jQuery has become!
One of the main tasks of the CEO Satya Nadella was an appeal to the developers outside their "fenced garden".
But there was a problem. Here is what Julia Lewson, vice-president of Visual Studio says in this release of The Changelog podcast :
We could offer nothing to a whole class of developers: modern, web-oriented, who work with Node and JavaScript — we simply had nothing to talk about. We simply could not attract these developers.
So VS Code was created to break this barrier and say, “Do you really know what, guys? We still have something useful for you. ”
Visual Studio is a heavy product in every sense: only installation can take more than half an hour. It supports a wide range of complex use cases relied on by corporate customers. Thus, there was no point in taking Visual Studio as a starting point and adding features to a new project on other platforms. And obviously, the idea of releasing Visual Studio for Mac or Linux was not particularly supported.
Therefore, Microsoft started from scratch, with no guarantees of backward compatibility.
In fact, not entirely from scratch: Microsoft already had some important parts, such as the browser editor Monaco. And since VS Code is a Node.js application (written in Typescript and running on Electron), they used the rich JavaScript ecosystem resources.
Open Source VS Code, easy, fast, extensible — surprisingly for a Microsoft product — has become a fashionable programming tool for advanced youth.
VS Code became the main editor for JS hipsters (chart from State of JavaScript Survey report , 2018 )
Both products are still being actively developed, and there is no indication that Microsoft intends to close Visual Studio.
findings
Unlike Netscape, Microsoft really managed to create an active open source community around VS Code. It has increased the efforts of developers to improve the product.
Of all the open source projects, Visual Studio Code ranks 13th in terms of stars on GitHub - coincidentally, just below Linux!
Of course, not every company can afford to lay out its main product for free access. But if open source is part of your development strategy, it makes sense to compare the stories of Microsoft and Netscape - and find out what Microsoft did differently for its community to flourish.
Another important factor: Microsoft has provided VS Code with a quality extensibility model , with the result that the community has already written about 10,000 extensions.
One of the latest conclusions from the history of VS Code is that over the past few years everything has changed dramatically: it is easier to create prototypes and software than ever before .
Despite the groans about the complexity of the modern toolkit , the JavaScript ecosystem has in the past few years turned into a veritable paradise of open source modules. In this regard, it is now historically unprecedented time.
4. Gmail and Inbox
Note: sunset icon
Inbox for Gmail was originally presented as an alternative minimalistic Gmail UX, “with a focus on what really matters.” He never tried to match the functionality of the original Gmail, and also introduced new features: thematic groups (bundles), pinned letters and deferred messages.
Some users, including me, enthusiastically accepted the Inbox. I always thought that Inbox is a demo version of what Gmail will eventually become, so I put up with the absence of some of the nuances of Gmail, expecting that they would eventually get to Inbox.
Two interfaces, one service
Inbox and Gmail worked on the same backend. In essence, these are just different user interfaces for the same service, and you could switch back and forth at will. This had its advantages and disadvantages: if there was no function in the Inbox (say, a vacation answering machine), you could always return to Gmail and configure what you need, although switching back and forth seemed strange.
However, after a while, Inbox stopped improving - it became clear that Google no longer invested resources in it. Naturally, four years after launch, Google announced the decline of the Inbox .
Like everyone else, at first I was angry about such a decision. But after spending a bit of time with the latest version of Gmail, I found that many of my favorite Inbox features were transferred to the original product : smart answer, hover actions, embedded attachments, and images. A few Gmail mailboxes are quite tolerably replaced by themed Inbox groups.
But not all of Inbox have been transferred to Gmail: for example, people are so used to the “pause mode” (snoozing) that they literally physically suffer without it.
findings
Inbox gave Gmail developers the opportunity to experiment with features without disrupting the workflow of the vast majority of users.
However, serving both versions on the same backend , Gmail has put severe restrictions on innovation .
Once again, Google has been widely criticized for closing the popular service. Of course, Google is constantly closing its projects , so nothing unexpected.
But in this case, the initial attitude of Google to Inbox led to believe that we have a demo version of the future of Gmail. As DHH would say, the sunset came out ugly: many people found it unpleasant to return to the old product and lose their innovative Inbox workflows.
I think for many people the transition would be much easier if all of its functions were integrated into Gmail before closing the Inbox.
5. FogBugz & Trello
Note: badges of sad decline and "money, money, money"
FogBugz is a particularly interesting case, because it is a product of Joel Spolsky himself: he gives an idea of how the principle of “never rewrite” interferes with real life.
Before Jira and GitHub Issues, there was a web-based ticket tracking system called FogBugz. Released in 2000, this system was the first product of the new company Fog Creek Software, which Joel founded with Michael Prior. And for more than a decade, FogBugz remained their flagship product. Initially, it was sold only as a boxed version for installation on its own servers, but later came the option of SaaS with payment by subscription.
FogBugz has become very popular, especially among developers who, in my example, read Joel’s blog and took his advice to heart. My company used the system for many years, it was a great product for its time.
FogBugz was originally written on classic ASP, which worked on Windows servers. When ASP.NET came out, Joel explained why he was in no hurry to update .
To install FogBugz on Linux servers, a company trainee wrote the Thistle compiler to convert classic ASP to PHP. By 2006, Thistle had grown into a proprietary programming language called Wasabi, which is compiled into ASP, PHP, and client-side JavaScript.
Strange Wasabi Story
Nowadays, developing your own proprietary programming language and compiler is, let's say, an eccentric choice. So it is interesting to see how it all happened.
At some point, Joel mentioned Wasabi in a blog post. Some thought it was a joke, so he explained that it was not a joke . A fellow blogger Jeff Atwood's head exploded from this news:
Writing in your own language is absolutely beyond the limits. This is a toxic solution that is so at odds with Joel's previous excellent and sound software development tips that people really thought he was joking.
Joel insisted that the decision made sense from a business point of view. Of course, theoretically, it’s not worthwhile to invent your own language, but if you evaluate every small step towards such a decision, given the technological context and the code base, everything seemed logical.
Reflecting on Wasabi in a meaningful essay entitled “Technical Debt and Wind Search,” former Fog Creek engineer Ted Unangst compares the process to traveling without a map:
, , , , . , … , , . -, . , . . , , .
- , . ? : «--, . . ». : . , , .
In any case, explains Jacob Krall, another former developer of Fog Creek, the decision sacrificed tomorrow's maintainability for the sake of today's development speed. And by 2010, steel comes bills for this debt.
[Wasabi] open source, , … , : . , . . Visual Studio FogBugz… Wasabi, … , . , , Fog Creek… , Wasabi.
By that time, FogBugz was already ten years old: it was a mature and stable product. As a side project, Joel launched Stack Overflow with Jeff Atwood (obviously, Jeff’s blown-up head had healed by then).
FogBugz was gradually getting older. Although the bug tracker market remained fragmented, Jira from Atlassian, which came out a couple of years after FogBugz, came to the fore. It has become the default choice, especially for large corporate users.
This particular inflection point in FogBugz history is really interesting to look at. Like Basecamp, they had a profitable, mature product. Yes, not so fashionable, and maybe it was not very interesting to work on it. Good or bad, but it has absorbed many years of technological change and new ideas on how to solve one specific problem: tracking of bugs.
Of course, there was a Basecamp option: taking into account all the experience, take and rewrite FogBugz from scratch. I suppose this idea has not gone too far, because we remember: “what can never be done”, “worst strategic mistake” and so on and so forth.
I recently came across an article in 2009 that Joel wrote for Inc. Magazine. His author’s column under the heading “Does slow growth mean slow death?” The tone is completely different from the usual self-assured bombast: it sounds introspective, uncertain, filled with doubts. Joel is worried about the rapid growth of Atlassian, reasons whether there is room on the market for several players.
I had to think. We have a big competitor that grows much faster than us. The company closes big deals with large, corporate clients ... Meanwhile, our product is much better, and we are a well-managed company, but this does not seem to matter. Why?
He decides to do two things. First, add all the features in FogBugz :
The task of the development team for 2010 is to eliminate any possible reason for which customers can buy trash of our competitors only because there is some small function, without which they absolutely cannot live. Honestly, I don’t think it will be very difficult.
Secondly, create a corporate sales department . Joel admits that he is not strong here, and finds this task unpleasant.
I do not know how these measures worked. The last time Joel mentioned FogBugz was in his blog in May 2010 , briefly announcing a new version.
New Hope
And this is what happened :
Around the tenth anniversary of Fog Creek Software, I began to think: in order to keep our employees motivated for another ten years, you need to start working on something new.
Therefore, they were divided into two teams, each of which made a prototype of a new product. The winning idea was created in the spirit of kanban board — a real offline board that is often used in software development projects: it usually looks like notes distributed across columns on the board.
Joel introduced this program as a management tool at a higher level than FogBugz:
Honestly, with all this fancy “project management” software, I could never properly track who was working on what ... As the founder of two companies, I walked along the corridors and saw dozens of people who pay to sit at computers ... and I had no idea whether they were doing their job correctly or whether they thought it was important what actually might not matter.
When creating Trello, Fog Creek developers got a chance to use modern technologies:
We use advanced technology, so it does not do without victims. The wounds of our developers are scattered throughout MongoDB, WebSockets, CoffeeScript and Node. But now they are interested. In today's tense labor market, talented programmers largely decide what they want to work on. If you give them an interesting product ... they will like it and they will love their company.
Trello supported plugins from the start, so third-party developers started helping:
API … , API, … . Trello , - , .
Programmers, of course, immediately understood the benefits of Trello, But there was nothing specific to the development of software in the tool. Joel described Trello as a useful tool for "everything where you want to keep a list of lists with other people ." Soon Trello began to be used for organizing everything in a row: from weekly dinners to weddings and dog-shelters .
While FogBugz was a vertical product - focused on a specific market niche - Trello was a horizontal product suitable for anything. Joel considers the “horizontal movement” of Fog Creek to be correct at that stage:
It is almost impossible to create a large horizontal product that is useful in all areas. It cannot be expensive, because you are competing with other horizontal products that can absorb their development costs for a huge number of users. This is a high risk and high reward: this way is not suitable for a young startup, but a good idea for a second or third product from a mature and stable company, such as Fog Creek.
To quickly scale to a very large number of users, Trello was initially offered for free. Later introduced a business plan .
In 2014, Trello was assigned to an independent company. Three years later, with more than 17 million users, it was sold for $ 425 million . Ironically, the buyer was Atlassian, the old arch-enemy of Fog Creek.
Meanwhile, back home ...
Fog Creek continued to develop another new product, a co-programming environment called HyperDev , which was later renamed GoMix and then Glitch .
At the same time, the FogBugz system was mired in obscurity. In 2017, someone decided that FogBugz was a foolish name in general, and engineering efforts went to rebrand the product as Manuscript . A year later - just a few months ago - Fog Creek sold the product to a small company DevFactory , which immediately returned the name FogBugz .
Under the direction of CEO Anila Desh, Fog Creek became a one-product company and changed its name to Glitch .
findings
I have a lot of thoughts on this.
The key to understanding the story is that Fog Creek has always cared not so much about bug tracking as it is about empowering programmers — starting with their own:
The main task: to create a comfortable working environment. We made personal cabinets for employees, they flew only first class, worked 40 hours a week, got free lunch, Aeron chairs and the best computers. We shared our ingenious formula with the world: excellent working conditions → excellent programmers → excellent software → profit!
Given this “formula,” you can make a logical and encouraging conclusion: Fog Creek has built a business around the happiness of developers. This was reflected both in the company's products and in its internal “operating system” . The first product, a bug tracker, served as the basis for launching a new product that solved a similar problem in a more abstract way.
From the words of Joel, it seems that the story of Trello is a search not so much of a new business, as there are opportunities to support the motivation and involvement of Fog Creek developers . A product worth half a billion dollars was just a pleasant side effect.
However, a little sad how it ended for FogBugz. I do not think that the developers of Fog Creek were particularly happy in the last days before the sale.
It is clear that there were bigger and bigger projects: Stack Overflow, Trello and Glitch - each one is much more useful and more valuable than FogBugz; and it is impossible for one person to keep track of everything. Therefore, I cannot blame anyone, in particular, for the loss of interest in FogBugz with a 20-year code base and strong competition in the market. But loyal users at least found a good home and did not receive a “sunset” type medicine!
However, the sentimental part of me would prefer to more worthily “honor the heritage” of all those involved in the creation and use of this product over the past years.
6. FreshBooks and BillSpring
Note: secret operation icon
The article has grown more than I expected, but I can not leave this story aside. Hold on, there will be an unexpected turn.
Stop me if you heard it before
In the early 2000s, Mike McDerment had a small design firm. He decided that accounting software was too complicated, so he used Word and Excel for billing.
Everything worked fine to one case :
The critical moment came when only a case was saved by an important invoice of a client - I just clicked the desired button. I knew that there had to be a better way, so I spent the next two weeks programming the prototype, which will be the basis of the current FreshBooks.
Mike is a designer, not a programmer, but he and two co-founders managed to assemble a tool that is good enough for several people to pay $ 10 a month to use it. It took almost four years to get the business out of the basement of the parental home.
By the 10th anniversary of the program (sounds familiar?) Freshbooks has become a profitable company with more than 10 million users and 300 employees.
But there was one problem. By the time the company managed to hire "real" programmers, they had a million lines of "founder code". An external analyst reviewed the code base and came to the conclusion:
“The good news is that you have solved the most difficult task. You figured out how to build a business, and you have a product that people like. The bad news is that you guys have a bad understanding of technology . ”
More importantly, in the existing product it was impossible to implement the existing ideas:
We founded the company more than ten years ago, the world changed, and we learned a lot about software development and the needs of individual entrepreneurs, which are becoming more and more common in society ... we knew that we needed to make some efforts to keep FreshBooks up to date in five years.
MacDerment is familiar with the conventional wisdom that you cannot rewrite the system from scratch:
Rewriting code from scratch is the biggest risk for a software company. Most likely, you do not even finish the project. It will take longer than planned, and will cost more. The end result may not appeal to customers. And there are no guarantees that the new platform will actually be better than the previous one. Rule number one in software is to not rewrite your software.
Thus, they made several attempts to clear the mess without rewriting the system from scratch; but “replacing tires on the go” proved impossible.
What happened next may surprise you
MacDermenta visited the idea of secretly creating the “competitor” FreshBooks.
He founded a completely new company in Delaware called BillSpring. She had her own website, brand and logo. Trying not to link the two companies, he instructed the external lawyer to develop new documents for her.
The development team implemented the “Lean UX: Designing Great Products with Flexible Teams” flexible development practices based on the book by Jeff Gotelf and Josh Seyden : Scrum teams and weekly iterations with feedback from real customers. MacDerment asked them to behave like a startup, and perceive it as a venture investor:
“You have four and a half months. If you enter the market, get more money. Otherwise, the end.
The team managed to release MVP a few days before the deadline. They bought AdWords keywords to drive traffic, offered users free accounts for the first year. Soon, customers appeared - and fast iteration cycles of the real product began.
At the end of the first year, BillSpring began to charge. At some point, a new product received an unexpected quality rating :
“One person called to unsubscribe from FreshBooks and go to our new company,” says McDerment. “It was a great day.”
Soon, they lifted the veil of secrecy and told BillSpring customers that this was a product of FreshBooks, and also notified existing customers of FreshBooks that the new version would be released soon.
Gradually, the clients of the “classic” FreshBooks made a new version, but they could always return to the old version if they wanted.
findings
The secret project FreshBooks did not come cheap: according to McDerment, they spent $ 7 million on it. However, after more than a decade of growth exclusively on their own resources, they raised $ 30 million in venture capital, so there was money. Not everyone can afford it.
Forbes estimated FreshBooks revenue in 2013 at $ 20 million. After completing the upgrade in 2017, they earned $ 50 million. It is not known how much came from the new product, but writing a system from scratch clearly did not slow down the company's growth.
MacDerment says that the process of developing and implementing new features has become faster and easier. More importantly, they now have a product in their hands that implements the best ideas. With this is not scary to look to the future.
In addition, the experience gained has changed the culture of the company - in a good way. When they pretended to be a startup, they learned how to work as a startup. Practices Lean UX spread to the entire team of developers. Customers are actively involved in developing new features.
FreshBooks went to extraordinary measures to protect itself from potential problems: introducing innovations under the fake brand, developers could completely rethink the program and take on big risks. Even in the worst case, they will not damage the existing brand.
All this seems a bit extreme. Perhaps such measures were not necessary. But this is a reminder of how serious the stakes are.
Some thoughts
It is generally accepted that it is better to avoid rewriting the program from scratch , and if possible to make gradual improvements. For the most part, I agree with that.
But the advice suggests that in the end we will get the original product plus a set of new features.
But what if you want to remove the functionality? Or implement some option completely different ? What to do if with ideas came a fundamentally new approach?
My conclusion from these stories is: as soon as you realize that the current version is very different from the imaginary ideal , then the new version should be released not as a replacement, but in parallel with the current one .
When thoughts arise to rewrite everything from scratch, it may be worth asking other questions. Maybe create your own competitor? If my product is FogBugz, then what will be my Trello? If this is Visual Studio, what will my VS Code look like?
If we compare Spolsky 's article about Netscape and the DHH post about Basecamp, then they agree on one thing: Legacy has value.
The good news is that you don’t need to throw away this value in order to innovate.
Source: https://habr.com/ru/post/441456/
All Articles