15 ms·

Why do we fall into the rewrite trap?

• austincheney 7y ago
  Rewriting from scratch is usually, but not universally a bad idea. There are times in your life when you encounter that piece of legacy internal software that is simply garbage. The math is simple if it takes less time to rewrite than to refactor then rewriting is better, but also keep in mind that estimating software efforts is often inaccurate. I have also noticed that in Agile teams refactoring is generally not rewarded and sometimes is even discouraged. Instead it is a voluntary effort taken at the developer's expense and risk, which is perhaps the greatest crime of Agile.
  • scarface74 7y ago
    Why are you “rewriting” instead of refactoring? Even if the existing code is “garbage”, if you need to add new functionality, you can usually use the “strangler pattern”. Put a nice facade over the old code to provide an interface and write on top of it. If I can do it by putting a COM wrapper on top of 20 year old PowerBuilder code and then interact with it with C#, I can’t imagine a case where this can’t be done.
    • Quarrelsome 7y ago
      I was once partially responsible for maintaining an old .NET remoting system that did absolutely nothing to isolate its transactional boundaries. The services were baked into the model which made it easy to write in the first place but very hard to refactor. The code would load a "hollow" entity and then as the entity was interacted with: automagically over the wire the data would be lazy loaded. If you applied an SQL trace you might see over 300 separate SQL commands executed just to load a page that visually represented the entity. This resulted in some dire performance outcomes, a simple for loop over a given collection on the entity could result in N round trips and sometimes even N*N depending on the data modelling in the back end for given types of data within a collection or association. A primary issue of this system is that lots of client code had been written that didn't express its intent. There were about eight relatively complex clients of this software and nowhere in that code base did the client ask for the data it wanted upfront in a way that would allow someone to refactor it without rewriting every single one of those eight clients. Now yes, you could refactor this "architecture-less" sub-system by replacing it with another "architecture-less" sub-system that was "better", but sadly you're left with the same problem: the clients will never tell you what data they need for a use-case they will just assume it will appear when its accessed. To add in those "data demands" you're performing huge shotgun changes across the entire code-base which are always too expensive to justify. One particularly egregious example was a WinForm loading an entity and then stuffing it into the .Tag of a control where a handler would cast it back out later and access it again in a lazy-loading kind of way. Your only hope in that case is some sort of static code analysis to attempt to reverse engineer the client's data demands but that's probably approaching as expensive as any of the changes.
    • Bahamut 7y ago
      It's not as easy to just refactor when it comes to UI oftentimes because you are often writing completely new UX.
      • scarface74 7y ago
        True, It was probably bad wording on his part when he said “rewriting from C# to Angular”. If he meant, “we created an API in C# and decoupled the MVC rendering from the business logic and rewrote the front end in Angular”, that’s different. Since he didn’t mention rewriting the back end, I can’t assume they rewrote the backend.
    • slowmovintarget 7y ago
      Microservice architectures, if you have the organizational scale to support them, are intended to produce services that can be rewritten and replaced. I've actually done this on purpose, by getting a v0 API into production quickly (1 week), then getting a v1 with all the bells and whistles out with sufficient time. It completely replaces the the v0 microservice which is a separate deployment. The first version provided a specific implementation of the functionality for a single, small user population. The full version scales to millions of users, globally. It is still small enough that we could rewrite it, if we had to. The infrastructure is actually harder to produce (as code) than the API functions themselves. CD pipelines, extensive unit tests, automated smoke tests, automatically configured health monitoring... all of these things make it possible to replace a service with a different implementation that conforms. It's a hard discipline to get to, but once you're there, it is often more economical to rewrite to move on. I guess that's not the case for the usual kinds of projects. We had to spend a year as an organization to get to the point where this was true. It's usually not worth the cost for small teams to do this.
      • Ididntdothis 7y ago
        I always wonder how micro services will do once a refactor doesn’t impact just one service but several services and teams. This seems to be a recipe for a lot of political machinations.
        • scarface74 7y ago
          If you have to change the API signature and not just add more information, you have to version it and have a decent deprecation schedule.
        • slowmovintarget 7y ago
          Part of the expense of microservices is that they be individually replaceable. Every microservice has dependencies to the interface of other services, and only the interface, which is typically RESTful. Refactoring in one code-base (read: one microservice), would never effect another code-base. The unit of reuse in this architecture tends to be the entire API, or libraries published as open source. If there is generic code that is suitable for a library, it is also suitable for contribution. If there is a core business function that should be reused, it is a microservice with an API and gets shared and consumed that way. Our hard rule for refactoring or enhancing services is if it is a breaking change: use another name (Rich Hickey's recommendation). If you provide more or accept less, fine. If you provide less, or require more, use a new route (like a /v2...). Therefore, refactoring in your code base, which makes your life easier, is transparent to everyone else who depends on your code. We have many small teams, so each team is providing 5 to 10 microservices, and refactoring within each independent repo is simple and low impact. There's no magic here, we simply paid the upfront cost of adopting an architecture that can be fielded by a very large dev organization, with a concerted effort in high quality DevOps practices. This move was also a means to scale the organization without dragging our efforts to a screeching halt with maintenance burden.
  • ayushgp 7y ago
    I agree. I recently worked on a price where 1 java class had 14 methods named construct<subtype>fields which all built a html+js+css mess using a string builder. I was asked to add support for 3 more subtypes. And this was the god class for the UI. We rewrote the whole UI in 3 months. There was no way that could be refactored.
    • gowld 7y ago
      A rewrite that small is a refactor.
    • james_s_tayler 7y ago
      That just sounds like garbage code to begin with.
  • clktmr 7y ago
    > The math is simple if it takes less time to rewrite than to refactor then rewriting is better This is the common pitfall with rewriting. It does not account for the existing software being tested in production for years. There often are subtle behaviors/bugs, that users by now rely on.
    • Psyladine 7y ago
      Joel's examples of hairy functions. "Why does this need to be 50 lines and makes half a dozen case exceptions? Just strip out that noise, god who wrote this?" Now legacy systems don't cooperate, well I guess they can just rewrite their APIs too because "software entropy".
      • clarry 7y ago
        So, unmaintainable undocumented untestable legacy code? Yes please, rewrite it, break it, and when its real intended behavior is understood, write tests and document it so the next guy doesn't have to wonder about that crazy function..
        • gowld 7y ago
          Please stay off my systems. If you deploy broken software that runs your business, no one has to wonder about any of the functions any more.
        • blowski 7y ago
          If you keep doing that, there won’t be a next guy. The company will be bankrupt.
          • clarry 7y ago
            That's why commercial software is doomed to be crap.
    • nilkn 7y ago
      In some cases, it's possible to rewrite incrementally via refactoring. (Whether you can do this depends on the architecture of the system and whether the starting and target languages have decent interoperability.) In other words, rewrite one small piece of a system at a time while maintaining the entire unit and integration test suite. While this doesn't completely obviate the risks you point out, being able to rely on existing tests can make the effort far more plausible and less risky.
  • BurningFrog 7y ago
    > I have also noticed that in Agile teams refactoring is generally not rewarded and sometimes is even discouraged As a long time Agilist, the spread of Fake Agile is a sad thing to see. Constant refactoring is a core Agile practice! https://martinfowler.com/bliki/OpportunisticRefactoring.html https://martinfowler.com/bliki/OpportunisticRefactoring.html
    • jcadam 7y ago
      Every "Agile" shop I've worked in was awful and has been doing it wrong according to Agile fans. "That wasn't true Agile" is starting to sound about as credible as "That wasn't true Communism." Best methodology: Self-organizing teams of experienced, expert engineers. Let them develop whatever process works best for the individual team and project. That requires two things: 1. Hiring the right people. 2. Trusting them. Most companies aren't willing to do this, so... we get a semi-unstructured form of micro-management hell which goes by the name "Agile." Regardless of whatever that term originally meant, this is what it means now.
      • Ididntdothis 7y ago
        “Self-organizing teams of experienced, expert engineers. Let them develop whatever process works best for the individual team and project.” That’s what “Agile” is when you read the Agile Manifesto. It seems every reasonable methodology quickly gets perverted by leadership to a top down, dogmatic dictatorship caricature of itself. Happened to OOP, Agile, will probably happen to FP. You could argue that what Lenin and friends did in Russia was also not what Marx had in mind.
        • thu2111 7y ago
          This is what agile proponents always say. Whatever someone is suggesting, that's agile. It appears to mean nothing. Here, you're saying that the agile manifesto literally says nothing beyond "let people make up whatever process they want", which boils down to nothing at all. If that's really the case then agile as a concept may as well not exist. But we have story points, epics, scrums, retros etc. Agile is very much more than that.
• softwaredoug 7y ago
  In my experience it’s a management problem more than a technologist problem. New engineering manager, wants to leave their stamp, has a grand vision, and is able to get buy in and budget from the higher ups. “Higher ups” in most companies don’t have the tech literacy to question such a move. And there’s a lot of ego going around to say “this time is different” when it’s really not. Usually when I see just a technologist push for a “big rewrite” they won’t succeed without management allies or enablers. One reason this happens is that management and technologists alike have a huge dearth of skills when it comes to dealing with and evolving legacy code. It’s not taught anywhere and has to be learned. It’s this lack of skills that CAUSES a lot of new shiny tech to come out, as it’s more fun to write my own JS framework than try to work with other people to improve theirs.
  • eej71 7y ago
    I agree. I think the other dynamic that I've observed in these situations is that the technologists who oppose the big rewrite often sound like a wet blanket who are just opposed to the excitement. The old curmudgeons are just raining on the parade of excitement. For some senior executives who are looking to generate passion and excitement the desire to endorse and support the big rewrite is just too much to resist.
• cottonseed 7y ago
  Obligatory comment I have to repost every time rewrites come up: https://news.ycombinator.com/item?id=11554288 https://news.ycombinator.com/item?id=11554288
• scarface74 7y ago
  The company had built heavily around .NET, which, while it has its merits, did not provide the type of experience that was best for this environment. And then he makes the same mistake that his entire article is based on. He needed to rewrite the code to use Angular instead of .Net? I’m assuming he meant he needed to use Angular instead of server side rendering. I can’t imagine a scenario where server side rendering wouldn’t have gotten the job done. Especially since he admitted that he didn’t need high UI performance.
  • radicalbyte 7y ago
    It depends, I've some some beasts built in ASP.Net Webforms. Worse than anything you'd see in PHP from a reliability and extensibility perspective (although factors better in security - Microsoft pushed their kludgy ORM hard back then whilst PHP tutorials started with string-based SQL). If I inherited an ASP.Net Webforms product which was built by amateurs from an MVP/PoC which would go on to form a very small part of a large product then I would absolutely re-architecture (and thus rewrite) it. If it's an existing product the the rewrite cannot be compartmentalized then there's no way I'd touch the code. In the scenario of an aging product I think that you're honestly better taking your best engineers and product people and starting again. At some point when the new product is mature enough you can look at how to move the last straggling customers over. I've seen that done successfully by clients and also by large companies (Microsoft with WebForms > MVC and later .Net Framework > .Net Core).
    • martinald 7y ago
      WebForms is pretty similar to Coldfusion. Which he spent the whole start of the article saying was fine and got the job done. There's nothing inherent in .NET that would 'not provide the type of experience that was best for this environment'. If anything, probably the vast majority of code that is written for managing 401Ks out there is probably written in .NET or Java.
• pron 7y ago
  I would ask a meta-question: why did the author fall into the trap of writing about the rewrite trap? While much of what the article says is true, it talks about a phenomenon that exists mostly in the funhouse mirror of HN and Reddit. People don't actually rewrite so much; in fact, they probably do it less than they should. Yes, there is a "contempt culture" but it almost always comes from the losing side. E.g. Go is not very popular outside the US, but it's hugely popular in America; how popular is it in the US for active development? 33x less than Java [1]. That's still very respectable, but let's not get carried away. Moreover, HN and Reddit are not only terrible at describing the current state of the industry, they're also terrible at predicting trends. While a few of the ideas/language/techniques hyped on such forums do end up successful, the vast majority end up failing. Some of them continue to be hyped on those forums even long after they've failed. Why do Reddit and HN paint such a distorted image? I have a couple of guesses. For one, by their very nature, they focus on new and unusual things, which is what they're supposed to. This means that by their nature they focus on things people don't actually do. For another, these forums can, at best, represent the content that's actually produced online, and here there is a big bias towards smaller companies -- perhaps because such content is an efficient form of marketing for them -- as well as towards places and industries where producing blog posts featured on HN is a part of the culture, namely startups and SV companies. Even there we see that an SV company like Google, that employs 2000 times as many employees as a startup, does not produce 2000 times the number of technical blog posts. When the content is so skewed towards small organizations, it gives disproportionate representation to the practices of small companies working on small codebases. When those companies grow, they tend to shift their practices and technologies to more established ones that are not as new and not as unusual, and also produce fewer technical blog posts. Similarly, younger, less experienced developers have more time and incentive to publish posts, and so are overrepresented, but as they mature the often realize, like their predecessors, the mistake of their ways, but also produce less online content. The result is that HN and Reddit mostly talk about things that aren't usually done, and overrepresent smaller problems and practices that come from inexperience. That makes them fun to read, but readers shouldn't forget that the genre they're reading is more that of GQ/Vogue than, say, the New York Times. [1]: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/ https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/
• Allower 7y ago
  How about advocating for good judgement instead of stupid absolutism's like this?
• Allower 7y ago
  If you believe this it just means you lack experience. Have fun refactoring your companies shitty code for the next 2 decades..
• m4r35n357 7y ago
  Because we did it wrong the first time.
  • apcherry 7y ago
    but it'll be so much better the second time!! https://news.ycombinator.com/item?id=22104506 https://news.ycombinator.com/item?id=22104506
• magicalhippo 7y ago
  Another aspect I didn't see mentioned was that, at least in my experience, one can put too much effort into solving a problem. Then one ends up with a nice bespoke solution, but once it's been used for a bit, the requirements change and the solution might end up being a poor fit. Very often in my experience this is because the client doesn't have a perfect handle on what exactly it is they want, which is only natural when venturing into the unknown. So they end up spec'ing a solution that doesn't exactly match the ideal work flow. These days at work, when the client wants some new custom feature, we try to figure out if we can get something good enough by making small adjustments to existing features. Then, when the inevitable changes come, we're in a much better position to determine the true requirements if we decide to go for a bespoke solution. This does however require that the code is malleable, so I write with that in mind.
• jasode 7y ago
  A reminder that Joel Spolky's essay being cited is about people rewriting ugly code that already works. That nuance is important because successful companies do invest in rewrites when there's an architecture change because it's the cleanest most economical way to do it. My previous comment of Microsoft examples: https://news.ycombinator.com/item?id=19245653 https://news.ycombinator.com/item?id=19245653 Another example is Google rewriting their early web crawlers of Python/Java into C++ to make them more efficiently scalable to thousands of machines. They also rewrote the frontend web server from C++ to Java. But some rewrites also failed such as Evernote's rewrite to C#/WPF. I think for the topic of "rewrites bad/good", it's better to list a bunch of famous real-world case studies and extract the common criteria that makes rewrites successful.
  • zaphar 7y ago
    I was around for the Google Webserver rewrite and it was actually a rewrite done by refactoring not clean slate. It's amazing what you can do with disciplined refactoring, even moving to a new language.
    • BurningFrog 7y ago
      If you have a decent test suite to lean on, you can work miracles this way!
      • wpietri 7y ago
        And if you don't have a decent test suite, you might as well build one. So much of a rewrite is archaeology, figuring out what elements of a system are intentional versus accidental. A great way to do that archaeology is to start weaving a net of tests around the existing system. Sort of like Fowler's Strangler Fig pattern: https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html
        • majormajor 7y ago
          Yeah, if you don't have a detailed test suite, and can't build one, you probably don't fully understand your requirements, and your rewrite is in trouble already.
• snarf21 7y ago
  I agree. Mostly you need refactoring to account for the changes in requirements over time. We don't spend enough time focusing on encapsulation and modularization. People want to rewrite because it is green field and they can do it how they want. As you said, this doesn't really add value to the company.
• growlist 7y ago
  Sometimes there's no option, because enterprise policy mandates that you have to port that uncommented, spaghetti code, dependent on archaic Win32 calls, written by amateurs VB6 image processing application to something modern like .NET. BTW if anyone needs that skillset I'm open to offers!
• rb808 7y ago
  The most important thing for developers is will they have the skills to get the next job or will they be working on technology that no one wants in a few years time. If FANG companies are hiring people with SPA, JS, Python experience it makes perfect sense to get rid of any technology no matter how well it is working.
  • sabana 7y ago
    .NET is amazing and very popular right now. Why would anyone get rid of it?
    • rb808 7y ago
      Agreed I like .NET I've modified the original to make it any generic technology that isn't hot in SV.
  • pjmlp 7y ago
    Those are the same companies that 5 years down the line discover why all big corporations bet on .NET and Java when performance matters.
    • dragonwriter 7y ago
      Big enterprises (corporations and government) have been betting on Java/.NET often without considering performance; they do it because the skills are widespread and the talent is cheap to hire (not necessary low salary, but easy to fill positions.) That's also why JS/Python is becoming attractive to them now.
      • pjmlp 7y ago
        They do when accounting sees the cloud renting costs to scale those js/python apps.
    • code_sloth 7y ago
      "Nobody ever got fired for buying IBM", or so the industry said for decades. But IBM wasn't (always) the best, they were just safe bets. Until the world started changing and they weren't. .Net and Java have always been good enough. Even today they're good enough for many, many problems. I probably would not reach for .Net and Java if performance literally mattered.
• pjmlp 7y ago
  Usually the way I turn down junior ideas about rewriting the whole deal is making them think about the monetary costs of a rewrite, and to show what is the benefit for the end customer from an cost / analysis report. Rewriting stuff is cool when one isn't paying the work hours expended in them.
  • thrownaway954 7y ago
    it's called investing in your product. if a rewrite will cost x amount in dollars and man hours upfront, BUT will save much more over the lifetime of the product in support and pain for both you and your customer, then it is ALWAYS worth it.
    • pjmlp 7y ago
      If that is proven for the use case in question, by all means. If not, then there are better places where to spend money.
  • wtetzner 7y ago
    The successful rewrites I've seen are usually because the requirements have changed so much since the original was written that the original code just isn't the right thing anymore, and refactoring it to be the right thing amounts to a rewrite anyway. Depending on what the software does and how it works, you can often have the original software running along side the rewritten software, and gradually move users over to the new software, giving you time to iron out bugs in a fairly safe way. Of course, that doesn't work for everything. It's easier for applications that are used internally by a company vs external customers.
• notacoward 7y ago
  10% necessary to fix the code itself 20% necessary to get into a better ecosystem (especially for hiring) 30% NIH 40% know it's bad but padding review/resume
• gumby 7y ago
  Probably the best section is right here: > However, refactoring can be a better tool before you begin making any changes as a way to make your change easier. As Kent Beck said “Make the change easy (warning: this may be hard), then make the easy change.”
  • gowld 7y ago
    Combine that with "Red, Green, Refactor" (write failing tests, fix code refactor) and we have another pair for the list of mutually contradicting proverbs.
    • regularfry 7y ago
      They're different development phases. If you've got a green test suite, you can just "Refactor, Green, Refactor, Green".
• agumonkey 7y ago
  do we have a model for differential structure migration back to formal specs ?
• krn 7y ago
  But isn't Firefox Quantum a result of a successful rewrite of Firefox Gecko?
  • kibwen 7y ago
    The thrust of Spolsky's argument is that you can't stop delivering just for the sake of a rewrite. If a rewrite happens, it has to happen in the background while your main product keeps shipping. Mozilla spent years letting the pieces that would become Quantum incubate in Servo, all the while still shipping Firefox as normal.
  • bwat49 7y ago
    its rendering engine hasn't been completely re-written though. They've been re-writing parts of it piece by piece.
  • cwzwarich 7y ago
    Firefox Quantum isn't a rewrite of Gecko. At one point, Servo was going to be a rewrite of Gecko, but that petered out. They pivoted to a strategy where some parts of Servo would be integrated into Gecko, and other components of Gecko would be rewritten in Rust. The most significant of these was Stylo, Servo's CSS style (but not rendering) subsystem. However, despite the rebranding, the core of the engine and the overall architecture is still Gecko.
• mr_nobody 7y ago
  The only times I had to rewrite the software was the time when initial documentation, didn't match what was actually delivered/expected from the client. Sometimes it's very hard to plan architecture when the whole concept change.
• scarface74 7y ago
  He kind of touched on it, but he really didn’t go into one reason to rewrite code is if it is based on old legacy technology that won’t be supported in the future. If your website was Flash heavy, you had to rewrite it for it to work on mobile. I mentioned another post where I was responsible for rewriting a legacy 20 year old PowerBuilder app that depended on sql server 2003. The first step I took was to upgrade it to a “newer” version of PowerBuilder that supported COM, put a C# REST API on top of it, and then create Postman/Newman integration tests. After that, we slowly started moving the code from PB to C#. Honestly though because everyone has their own self interest at heart, sometimes you have to rewrite or transition to newer tech to keep existing employees and/or to get new employees. I was at a job where the department grew from 4 to 15 developers in a year. The product was a B2B product where we had 90%+ of the sellers market using a PHP web app with complicated business logic. We didn’t have a product for the buyers market. We were going to put COM on top of the (well written) PHP rules engine and share it with a new product for the buyers written in C#. The buyers product written in C# didn’t find a market, but we were getting interest in expanding the PHP product. Every single developer left within 6 months because no one wanted to spend the next year doing PHP. We all knew that PHP wasn’t marketable at the compensation rates we were looking for. The only reason it took six months for them to leave is because some were waiting for their 3 year vest.
• mbesto 7y ago
  > Just like in Joel's post, where Netscape took years to rewrite its already working code, rewriting code because Coldfusion was “dead” or “inferior” would have served little business purpose. I understand there are plenty of counter-arguments to be made here. First and foremost, it gets harder every day to find a Coldfusion developer. Those who know the platform are most likely looking to give a facelift to their skillset, rather than prolonging the inevitable drying-up of the proverbial job pool. More, it may be harder to implement functionality in Coldfusion, particularly the kind we were dealing with, than, say, in .Net, Ruby on Rails, or even Go. Even so, there are other, better ways to move toward new technology without rewriting an entire codebase. Interesting that the author doesn't provide any real suggestions to this specific case, only the other examples, which are not similar. The facts are the following: 1. The Coldfusion community is dying. 2. Adobe is actively making it more difficult to commercially pay for the software. They are now seeking compensation for use of CF as part of "SaaS Revenue". You have to submit a form that says what your revenues are. I kid you not, thats what the sales people are saying to customers. These two situations have serious economical ramifications on a company running CF.
  • slowmovintarget 7y ago
    When the answer to "what is your pricing?" is "well... how much can you pay?" the vendor gets kicked out on their tuchus in our shop.
    • gowld 7y ago
      How much do you charge your customers?
      • slowmovintarget 7y ago
        I don't ask them what's in their bank account. We study the market and price our products accordingly and competitively.
      • marcosdumay 7y ago
        Well, I work in a government so... But anyway, the problem of that behavior is not really the pricing, it's all the rest that comes bundled with that attitude.
• xondono 7y ago
  My feeling is that rewrites simply don't scale well. To make them work you need resources, good planning and motivation from everyone involved. As the number of people increase the probability that any of them made a mistake estimating how long it will take or how well their part will run explodes. That's why refactor tends to work better, rewrite with a scope. I worked at a company were we build small embedded devices (EM dataloggers). I was supposed to take an existing code base shared by several products and modify it to build a new one. The code was beyond ugly. As an example: delay_ms(5) Would yield a 5 milliseconds delay, as long as you weren't in a variety of modes, the GPRS connection wasn't hang up, and GPS had a lock. It was painful to think about it, let alone work with it. I convinced everyone that a total rewrite was necessary, and then I let everyone keep working on the old code base while I worked on the new one to add the basic functionalities. Then we started to move product by product, adding the "extras" each device required. Now the new products are built with that skeleton, and refactors are way less scary and faster, and can be made across devices easily (one of the improvements is that "business" logic has automated testing now). To this day I'm convinced that the only reason that could be made is because we started with the new product, and then moved upwards. Trying to build a new ecosystem for all of them would have failed hard.
  • commandlinefan 7y ago
    > rewrites simply don't scale well. I learned early on that rewriting a codebase is a lose-lose proposition: I’ll never suggest or recommend it again. Not because I don’t think it’s ever a good idea, but because it can only go wrong. If everything happens perfectly without a single hiccup or surprise, you’re still right back “where you started from” from the perspective of management. I worked on a massive rewrite porting a C++-based codebase to Java. The rewrite was actually suggested by “the business” because they were having trouble finding C++ developers and they noticed that Java developers were easier to come by. I was actually hired because I had a strong background in both, so I jumped right tin. I was too young and too naive to realize how backstabbing, conniving, and treacherous business people can be: I actually ended up being blamed for every surprise that came up during the rewrite process.
  • thrower123 7y ago
• GrumpyNl 7y ago
  The biggest trap is new and shiny. Let me explain, they decided in the company to do a complet rewrite while we only needed a few apis connecting to the existing software. Its a group of 8 people. The current software is written in PhP, jQuery, Mysql and some use of Yii. Blazing fast, customers are happy. New guys come and of course we need a rewrite. Everything has to be microservices. Now they have to work in Kubernets, Docker, React, Node, elastic search, MongoDb. With each of these is nothing wrong, but its a lot of new technology to pickup with 8 people. Now the clients hear when they want a change or modification, no just wait till we have platform 2.0. Long story short, development has gone downhill, customers unhappy and after 6 months they are already 12 months behind schedule. This company will byte the dust within a year.
  • phendrenad2 7y ago
    A very common story. Engineering managers need to be aware that their engineers will cry for a rewrite and say there's too much "technical debt", but it could easily destroy the company if you let them go hog wild with the rewrite. You need to quantify the benefits up front and make the engineering team meet the milestones, none of this "yeah we're polishing the codebase because reasons"
  • Ididntdothis 7y ago
    A lot of rewrites end up trading one set of problems with similarly sized set of different problems. But to be honest the rewrite was probably a positive for the devs. They have more cool stuff on their resume and will do better in the market. That’s one of the big problems with finding jobs. If you do what’s good for the company you may quickly end up with an outdated resume and be marked as dinosaur who hasn’t been keeping up. Even your own company will hire new people for new sexy projects instead of the people who did what was good for business.
• baud147258 7y ago
  The company where I'm working is doing a full rewrite of one of its product from a single-tenant, installed on-premise to a multi-tenant solution in the cloud. Except that the previous version is still worked on (new features & fixs), with perhaps less people than a few years ago. And the new version is developed by new teams set up for this project and the targeted market seems a little different. Well we'll see in a few years how it ends.
• aidenn0 7y ago
  Something I've noticed over the years is that the people who say that reading code is harder than writing code are people who have been writing code for a long time and are paid to write code. I think the truth is that it's actually a different skill, and one that's much harder to pickup because when you write code, there's a very quick feedback loop telling you that you're wrong, but you can read code, think it does something different than it does and never ever learn you were wrong.
  • Ididntdothis 7y ago
    I think reading code is very good for one’s character. It teaches compassion and openness to other people’s ideas. Pretty much like listening without prejudice. I am very guilty of not being interested in what other people did so now I am making a point to really trying to understand code before criticizing. It’s so much easier to throw a fit and think everybody else is stupid.
• rafaelvasco 7y ago
  A programmer never starts from scratch. Every new line of code typed brings with it the legacy of past struggles and new understanding;
  • deleted 7y ago
    [deleted]
• resu_nimda 7y ago
  What if the rewrite was intended to be competing product rather than a replacement for the existing one? So many rewrites die as they attempts to reach parity and acceptance from users of the legacy version. When a startup comes along and "disrupts" a product with their fancy new tech, they have basically done a rewrite without caring about the state of the legacy product. And then the incumbent often acquires them for a lot of money. So, why not just do that whole process in-house?
• caseysoftware 7y ago
  > If your reason for rewriting the code is that you don't understand it, you should not rewrite it. This is a fundamental thing that most people miss. If you don't understand the code/system/structure/process/law, you can't possibly rewrite it in a way that is a) effective and b) addresses the use cases it was designed to address. If you try to rewrite something you don't understand, everything after that decision is re-discovering the same old pains, lessons, and practices that the first person discovered.
• zzzeek 7y ago
  Don't fall into the trap of "never do X" prescriptions written in blog posts. Rewriting an application or library from the ground up is often a joyful experience packed with an immense amount of lessons to learn. Similarly, refactoring an existing application and watching it come back to life can also be a joyful experience packed with an immense amount of lessons to learn. Whether or not you know what you're getting into on either side, you'll learn soon enough, and experiencing both approaches many times over is part of what being a programmer is about.
  • goto11 7y ago
    If you are just developing for your own enjoyment, sure, you can rewrite for the learning experience or for fun.
    • zzzeek 7y ago
      if you are clever enough, you can get your employer to go with either approach you choose and you can learn while getting paid.
• WrtCdEvrydy 7y ago
  > Coldfusion (you've probably never heard of it), I still use it.
• hinkley 7y ago
  One of the oft-unspoken things about refactoring is that it's a way to do a rewrite without anyone noticing. Essentially it's the Ship of Theseus gambit: https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus Later on I realized a sort of reverse Catch-22 in this: The people who are most capable to do a rewrite are also the least likely to ask for one. They will just do it. An official rewrite often just becomes a pressure release valve. During the early stages nobody can measure how the team is doing, so the team gets a break from scrutiny. Whether that's healthy or not comes down to a lot of factors, but the odds are in favor of it being unhealthy.
  • darau1 7y ago
    I rewrote two applications, once on my own, once with some help from the team. The first time we switched the backend to a completely new framework (I'm in the middle of one of those right now...) and the second time we upgraded from an outdated version of the framework to the latest one in one go (so, essentially a rewrite from the ground up). Both times sucked, both times we underestimated the amount of work to be done, and both times we were much happier with the new product than what we had before.
    • hinkley 7y ago
      If the team refuses to work on the old code, you have to do something. A rewrite may be the least bad thing you can do in that case, but if you don't ask how we got here and why we won't end up right back here again... The Relentless Improvement model that many refactoring advocates espouse is one (great) answer to that question. But it also means they won't wait for a rewrite. They'll fix the bullshit they're staring at today, and stare at some other bullshit tomorrow.
      • mntmoss 7y ago
        Lately I've been testing a "third way" of thinking about refactor/rewrite decisions, which is to first document the existing requirements. The trick is in making those docs so small and lean that they fit neatly in comments inlined with key functions, and this I have accomplished by reduction to a list of "must" and "cannot" (abbreviated to + and -) bullet point items. It must function like this, it cannot function like that. Some requirements can be turned into automated tests or static checks, others need an eye to verify. But the cycle I'm seeing often works out to be: write speculative requirements, write speculative code, then reverse-engineer true requirements and maintain code against that. Doing this creates a base quality bar that the code has to hit in both the rewrite and refactor cases. The trap that rewrites tend to fall into is that the requirements are lost during the rewrite, so the new code becomes just as speculative as the original greenfield code. If you have the requirements as your reference, on the other hand, the area of bad code you can write is limited to the boundaries of those requirements and any missing requirements. This makes new code much less of a gamble.
• deleted 7y ago
  [deleted]
• softwaredoug 7y ago
  Rewrites are a symptom of orgs that focus only on feature velocity, and not other forms of customer value. If in addition to getting features done, teams were held more accountable for uptime, performance, and stability, there would be appropriate focus on careful redesign, but only in proportion to some customer end-value after that is delivered. A rewrite for the sake of a rewrite, because X doesn't conform to software engineering technobabble is a huge red flag. These things exist to support customer value, and are not ends in-and-of-themselves. In short, there shouldn't be a difference between new feature delivery and refactoring to support some other customer need (like uptime or performance). It's all work that needs to get put into a backlog, prioritized, and delivered with clear success outcomes
• cratermoon 7y ago
  Does anyone know the error handling pattern the author mentions?
• 0xff00ffee 7y ago
  This came up a few weeks ago regarding crypto. There's a distinct difference between rewriting code WITH a regression suite, and rewriting code WITHOUT a regression suite. The difference is enormous. I come from a hardware background where the # of employees looks like this: lead architects = N employees microarchitects = 10 * N employees circuit designers = 10 * 10 * N employees validation = 10 * 10 * 10 * N employees It is rough, but true: 10 lead architects can equal 10's of thousands of validation engineers There's a reason why it is so upside-down: bugs cost a lot more in the hardware world than in software because they are much harder to fix in the wild. The answer to the question, "Should we rewrite?" is always "maybe", and then requires risk exposure analysis and a robust mitigation plan. You need regression testing and a bug tracking system from day one, but you also need a rollout plan and a response team. It is not an easy decision for established software. Or rather, it shouldn't be! :)
• jldugger 7y ago
  > One of my favorite reads is Joel Spolsky's Things You Should Never Do. He wrote this post almost twenty years ago, outlining the downfall of Netscape and others because they spent years rewriting working code. I've read that piece long ago, and over time my cynicism has ripened. Should I be surprised that the opinion of a former Microsoft employee is that Netscape's downfall was their own fault?
• mark-r 7y ago
  > If your reason for rewriting the code is that you don't understand it, you should not rewrite it. Which is just another example of Chesterton's Fence: https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_... I once lived through a complete application rewrite. The rewrite was necessary to add a new feature that didn't fit into the existing code organization. We were able to reuse large parts of the old code, but it still took twice as long as estimated. And the result was the most bug-ridden version of the app ever. But ultimately it was successful, and the new feature was much loved.
  • mpweiher 7y ago
    And again: it depends. I was involved in at least one rewrite where large sections of the original code were incomprehensible, and rewriting the whole thing from scratch proved a massive success.
• hasbroslasher 7y ago
  Parable: Company wants to move "into the cloud" and adopts AWS managed services or Kubernetes to recreate and re-platform existing and functional, though sketchy, on-prem services. "Agile coaches" and "Solution Architects" advise rewriting the old code because of its fundamental alien-ness in a cloud-only environment. So it's a rewrite. But of course, the re-write doesn't work, primarily because of fundamental misunderstandings about what properties allow software to scale across many machines, in many time zones, running processes 1000's of times per day. So it becomes necessary to either cut losses and re-write the re-write or decide to start iterating now on the crappy re-write to make it closer in terms of functionality to what already existed in the crappy on-prem systems - which begs the question of why you didn't just iterate on the original sketchy code in the first place. There are times when rewriting does make sense - rare though they may be. I've only seen a few, and they always had to do with improving stability and reducing the potential for bugs. None of them required you to use the latest shiny to "completely reimagine what software could be doing for your business". I've helped to rewrite subscription-management systems that ended up noticeably reducing churn and cutting out spurious chargebacks from customers who couldn't navigate our bug-prone subscription service wasteland. But some refactors are so labor intensive that they amount to re-writes, even if you're using the same tools and languages. Some code is acutely awful and it needs to die for people to be able to go to sleep at night without having to drink a fifth of whiskey beforehand. Some atrocities don't need to exist. But, again, if the reason for a refactor or rewrite is summed up as "we're bored and want to play with these new shinies" then you are in for it. If rewriting provides you with some sort of new business capability or fundamentally changes a business process drastically for the better, then go ahead. But in my experience, if a technology or paradigm is fundamentally "so much better than what we do now", then it should work so well with what we do now so well that it doesn't require fundamental rewrites of large software systems. So rewriting things in Python or C++ is great, or using Kubernetes instead of Lambdas or whatever is fine, but it's more important that these paradigm shifts can be incremental rather than a complete recreation of what already exists, that the gulf between refactoring and rewriting can be relatively small instead of two completely different processes.
• mpweiher 7y ago
  While you should be careful about rewrites, Joel is not correct that a rewrite is always a bad idea. I've been (reluctantly!) involved in a bunch of rewrites in my career and they were invariably highly successful. So, as always: 1. it depends, and 2. please use your best judgement.
• carl_sandland 7y ago
  This notion of code being "done" is the root problem. This idea that you write something and ship it and that's over is wrong. Code is never done, it is almost biological in its emerging complexities. The current code is the running manifestation of everyone's understanding, of the architecture : it will and must change. Viewed through that lens you can see; * estimation is hard, as you are never really done. * software has a very high maintenance cost, plan for it. * architecture and design are important, longer term : spending more money on things with longer value life just makes sense. * Interfaces are important and allow for rewrites on a smaller scale. * you will always be releasing: focus on CI and devops to take the grind out of that. Rewriting is a form of refactoring I guess: It's like chopping a leg off or something. One thing I like about microservices (or rather, strict boundaries) is that you can rewrite the worst part but keep the rest going. Yeah and oh man I hate the "this code sucks" culture :(
• bob1029 7y ago
  My policy on rewrites is that you must already fundamentally understand not only the code but also the business that the code covers. If the developer responsible for the rewrite satisfies this constraint, I have a much greater deal of confidence in the success of the effort. Also, any rewrite should be done in contrasting terms of: Value to the end customer VS long-term technical value. Many rewrites remove value from both ends of the scale. Some may improve both. I think as long as you keep this equation balanced you will be ok. Many developers have ulterior motivations which can greatly compromise this equation if not carefully accounted for (e.g. chasing shiny things, resume padding, etc). I would say that in purely technology terms, rewrites are amazing. My approach to writing a new system usually involves writing it 2 times at a minimum. The first pass is the fastest, hacky way I can get to MVP with a major focus on the most difficult technical aspects of the product. This pass is what I put in front of our internal developers to get some input so that I can quickly correct course if needed. During this time, I allow myself to make sloppy mistakes in favor of proving that a certain feature can (theoretically) work. This seems to do wonders for productivity because you are much more likely to experiment and find better paths when you aren't worried about your extremely pedantic code policies (of which we have many). The 2nd pass (aka the rewrite) is when I have the first pass project up on the left hand side of my monitor, and a new solution on the right hand side. I use my original implementation as a reference, but now view it through the lens of auditing another developer's code for quality and policy. Having already proven that the hard thing can be done, my mind is now free to focus on the correctness and standards applied throughout. This is the code that I would actually put in front of our customers. From this point onward, unless a major shift in framework, architecture or language is decided, all future iterations are done on top of this 2nd pass codebase. I would also say that just because you decide to do the rewrite doesn't mean you have to throw away the old code and any support for it. The most successful rewrites I've ever seen occur where the legacy system is ran in parallel with the new system with both being maintained and used in production simultaneously. Obviously this has some overhead, but it also ensures you have a stable fallback option with clear A/B comparison capabilities throughout the migration phase.
• crimsonalucard 7y ago
  I feel if you need to rewrite something you're already in the trap. Rewriting is climbing out, not rewriting is digging deeper. The problem with rewriting though is sometimes it's another trap, but anytime you feel the need to rewrite... you are already in a trap.
• hnick 7y ago
  I saw a link here on HN a short while ago (though I can't remember where exactly) to a Ribbon Farm post talking about Legibility, or the idea that people generally like things that can be understood and categorised. https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/ https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-call... It seems to capture the idea of The Grand Rewrite fairly well. From the post: - Look at a complex and confusing reality, such as the social dynamics of an old city - Fail to understand all the subtleties of how the complex reality works - Attribute that failure to the irrationality of what you are looking at, rather than your own limitations - Come up with an idealized blank-slate vision of what that reality ought to look like - Argue that the relative simplicity and platonic orderliness of the vision represents rationality - Use authoritarian power to impose that vision, by demolishing the old reality if necessary - Watch your rational Utopia fail horribly There are often good technical reasons for a rewrite or major refactoring, but more than once in my career the urge was definitely based on the fact that if we rewrite it then we will know it inside out and we will only have what we need, nothing more. Full control and understanding.
• ablekh 7y ago
  Quick question, since we are on the topic: do you think that it is a feasible (or even the optimal) approach to first develop an MVP, using a very productive, but much less performant, language (Python) and then, upon reaching a product-market fit, if needed [i.e., after trying to remove performance bottlenecks and using a faster compiler, like PyPy], rewrite the product (SaaS platform) in a more performant and otherwise more suitable language (e.g., Julia, C#)? P.S. By "rewrite the product" I meant rewriting only the backend.
• Sophistifunk 7y ago
  People not wanting to write Cold Fusion isn't "contempt culture", it's an objectively terrible platform.
• luxuryballs 7y ago
  What if it’s written in ASP classic and powered by deprecated SQL procedures that won’t run on anything newer than SQL Server 2005?
• luord 7y ago
  Depending on the size of the refactor, the lines between it and "rewrite" start to blur, so I'm just going to consider what I'm doing right now at my job a big refactor of how the data is stored and read, even if it involves making some big changes to the database models and how they are interacted with. Really, it's pretty much a rewrite of the database handling code but hey, that won't impact how the data is sent through the endpoints so the interface didn't change. Refactor!