[galaxyLogic]

I think there's a myth that rewriting software is bad, or at least a symptom of badness, and "reusing" software is ideal.

But writing software is really like creating plans: plans for what the machine should do. Of course there is much room for reusing old plans as components of your new plan. But still every plan must be about what is needed at the moment, not about reusing existing plan-components.

In human communications we don't "reuse" old communications much do we? Well maybe we do a bit, using common utterances. But those are more like idioms of the language, not "subroutines".

[marginalia_nu]

> I think there's a myth that rewriting software is bad, or at least a symptom of badness, and "reusing" software is ideal.

There's also a weird opposite myth that old software is bad, and urgently needs to be rewritten with newer paradigms.

I'm currently hired to replace a piece of extremely stable '90s software with hundreds of janky eventually consistent microservices because for some reason. That's how software must be written nowadays, and doing it that way makes it better in some unspecified fashion.

It's not at all clear what is broken and what we're trying to improve with this work. But it's top priority.

[pjerem]

Haha, yes. My first front end job was to rewrite a totally reliable and working software written in an obscure javascript framework, but still, working pretty well, appreciated by the users, and making tons of money for the company.

Well, AngularJS was such a trending thing that we HAD to rewrite everything in it. For no reason. No new feature. Bonus time : i was the only dev on this project (because i was replacing the only front-end dev who was leaving) and i had not a single idea of how AngularJS worked at the time.

No supervision, no prior experience, no business goal. I'm not proud of the result. But at least i learnt a lot of things (including CoffeeScript, i'm sorry for who took the codebase after me).

[908B64B197]

> There's also a weird opposite myth that old software is bad, and urgently needs to be rewritten with newer paradigms.

Some of the challenges with old software is the ecosystem around it. Is the language it's written in still supported on modern OS? (Visual FoxPro for example). Is the database it's using still around? What about the libraries? Are they tied to a certain runtime version with no update path? Do you even have access to the source code for these dependencies? Or the application itself? Can it build on a recent machine?

I've seen projects where some infrastructure around an old piece of code was re-written to make it run on modern platforms, but that takes good engineering (some assembly required) that companies often simply can't afford.

[2muchcoffeeman]

My feeling is that rewriting is used as blunt weapon when the developer lacks the inclination or skill to learn what was written before. I’m been guilty of this.

[Silhouette]

That certainly happens but rewriting also happens because what is already available doesn't get the job done and can't be customised so it does.

One of the curses of modern software development is that so many of the resources we rely on are highly opinionated. We have frameworks and toolkits and scaffolding scripts and proprietary formats and convention-over-configuration to do things that could have been done with flexible, self-contained libraries and open standards.

These opinionated resources are often easier to create but they can cause great harm over time as a small application that got a boost from using them initially grows into a large application with changing requirements. Maybe those requirements can't easily be met if nothing composes and nothing can be adapted and each dependency becomes a fight between the direction its developers choose to take it that might not be right for the application and the need to keep updating because the developers don't want to support older releases of their code with essential bug fixes and security updates any more.

In this kind of environment, it is hardly surprising that some teams prefer to build things in-house even if they are reinventing a few wheels. It is sometimes the only way to retain control of your own code or to regain that control after the technical debt becomes overwhelming.

[commandlinefan]

> lacks the inclination or skill

Or the time. When you've been given a hard one-week deadline to produce something, you can commit to writing something that works with a lot more confidence than you can commit to figuring out somebody else's piece of garbage.

[2muchcoffeeman]

Most rewrites I’ve seen are huge system replacing projects that came over budget and often missed requirements. I’m not saying there are no legitimate reasons for rewrites. But when people bring it up, I think you need to ask a lot of questions.

[908B64B197]

I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better.

If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL there's no incentive to help the company succeed. Especially with non-technical management, the best thing to do for ICs is often to aggressively rewrite (in the language that's trendy right now and that better companies use) and get promoted by showing off a significant output. Then jump to a better company having spent a year training on their stack at the previous company's expenses.

[raverbashing]

But even if you know what is written, good luck making that PHP 3 website keep up with times.

Or that old C library written for old versions of OS/other libs.

[islon]

Agree, but you are giving a more extreme example.

Most rewrites I saw was "wow, this Java code from the old team is a mess, let's rewrite it and, in a couple years, the new devs will think the same about our rewrite."

[galaxyLogic]

I think you're onto something there. It's hard to understand code. So maybe the best way to accomplish that is to rewrite it. That way you will have inhouse people who understand and can maintain the software your business is running on. Once those people are gone it's time for the new recruits to rewrite it again. It's a continuing process.

[goodpoint]

...or a tool for CV-drive development.

[mettamage]

I suppose if you squint, then rewriting software means: properly reading/understanding the old code.

Sort of.

[eternityforest]

A lot of software isn't quite like a plan. It's more like a training manual with hundreds of plans for different scenarios and rules for choosing them and how to modify them.

People who write individual plans don't reuse them or believe in reuse. They're useless once the plan needs to change.

People who write metaplans aren't solving problems, they're trying to to solve general classes of problems, like "Manage booking at any business that has things that are booked"

[devnull3]

> But those are more like idioms of the language, not "subroutines".

Actually a lot of mechanical manual work we do are subroutines.

Examples

1. Make an omlette (params like: which kitchen or ingredients are derived from context)

2. Change engine oil

3. Take blood sample

[dgb23]

From Alan Perlis' Epigrams[0]

> 14. In the long run every program becomes rococo - then rubble.

And;

> 15. Everything should be built top-down, except the first time.

I think these are helping to understand the lifecycle of a project.

A first top down design should be understood as a draft, a direction. With experience these drafts get better, but the act of bottom up programming is necessary to discover details, problems and requirements that inform a more robust and flexible design.

A rewrite can be partial or total. Maybe it is enough to refactor some components, maybe a new design was discovered during the initial iterations, which yields a system that composes and evolves more robustly and works better as a whole.

As a web developer I program user facing applications, so there is always a kind of pressure to have highly domain and feature specific interfaces. Just get it done, move to the next.

But by learning from the Lisp world [1], Out of the Tar Pit [2], software design books [3][4] and the pain of experience, I've come to the conclusion that there is a better way. There is often a general layer that wants to be discovered that we can use to build the needed features. A workflow, framework, DSL or maybe just a bunch of functions or a data model.

This layer is often very hard to get right the first time around, especially if we don't have strong analogies already. It is often more natural to discover it by writing or trying to write the specific code first. Premature abstraction is the root of all evil.

But also [0]:

> 7. It is easier to write an incorrect program than understand a correct one.

We should be brave enough to move forward, while assuming that we're probably wrong. Scientists often practice this principle and try to figure out in what ways they _are_ wrong. I think this is a good way to approach programming too.

[0] http://www.cs.yale.edu/homes/perlis-alan/quotes.html

[1] https://dspace.mit.edu/handle/1721.1/6064

[2] http://curtclifton.net/papers/MoseleyMarks06a.pdf

[3] https://web.stanford.edu/~ouster/cgi-bin/book.php

[4] https://mitpress.mit.edu/books/software-design-flexibility