5 ms·

> 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

• 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.
• dkarl 7y ago
  This is why it's worth the effort to make behavior clean, coherent, and logical. "Huh the behavior of this system is a little eccentric, but if I insert my code in just the right place, I can get it to do what I need!" This is how legacy systems get built. Instead you have to ask, "How can I describe what this system does in one or two sentences?" "How can I describe how it does it in a short paragraph?" The first explanation should make it clear why you're building the new functionality into or on top of the system. The second explanation should make it clear how the system supports the new functionality and why it works. These two explanations form a team's shared understanding of the system. If you build a new system that conforms to this understanding, porting is straightforward, even if you don't replicate all the details. Invariably, though, there are developers who are too lazy to ask how a system works, and instead crawl through the code sticking their new feature in likely-seeming places and leaving it in the first place where it seems to work, regardless of whether the reason it works is related to the shared understanding of the system. Because everybody else must keep this new feature working, there can be no understanding of the system separate from the system itself: there is just a mass of equally significant details. The intentional developers are reduced to the level of the random developers. There is no such thing as a rewrite of a system like this. All you can do is replicate it nut by nut, screw by screw, and then it still doesn't work because you didn't match the spacing of the screw threads. The corollary to this is that if you build a complicated enough system, with an abundance of distinct places to plug in code, the random developers will always find a place to stick their code and will always be happy and "productive." This is the way to achieve architectural immortality inside a company: create something so complex that it can't be understood but solves every problem if you look hard enough.