I don't let myself rewrite code from scratch until I've made and reviewed an Anki deck that explores my questions about how the old coffee works. This is enough of a hurdle that I usually just end up refactoring the original code instead.
Things You Should Never Do, Part I (2000)
81–90 of 104 posts
Re: Things You Should Never Do, Part I (2000)
#82I think people tend to want to rewrite software for the psychological break from the old, bad and ugly thing they don't want to have anything to do with anymore. It is so easy to think "If only I could start everything from scratch, life will be so beautiful and I will be so successful and everybody will be happy. I will fix all the problems of the current codebase and people will forever sing songs about how amazing…
> developers not really understanding Rewriting software is an excellent way to gain such understanding. I only understood what GNU autoconf was doing when I was in the middle of rewriting its core functionality in pure GNU make. And who knows? You might actually make a better wheel against all odds.
Or make one you don't understand the purpose of, rewriting GNU Autoconf in GNU make would serve no purpose since what Autoconf does has nothing to do with building, but rather finding out details about the running system.
Maybe you were thinking of GNU Automake ...
Re: Things You Should Never Do, Part I (2000)
#83Earlier quoted context omitted.
[flagged]
I only have surface-level knowledge of any of these things, but I don't think most people would consider a defeated slave rebellion or a war of independence as "revolutions" As for the other two ... maybe the people of those countries would have endured less suffering afterwards if they had reformed rather than revolted?
>war of independence as "revolutions"
The war of independence the 13 American colonies waged against Britain is generally called "The American Revolution", but yes, for some reason most other wars of independence aren't called revolutions -- for instance while there was a Mexican revolution in the early 20th century, the earlier war of independence against Spain is just called the "Mexican war of independence" (Guerra de Independencia de México)
Re: Things You Should Never Do, Part I (2000)
#84Earlier quoted context omitted.
> developers not really understanding Rewriting software is an excellent way to gain such understanding. I only understood what GNU autoconf was doing when I was in the middle of rewriting its core functionality in pure GNU make. And who knows? You might actually make a better wheel against all odds.
Or make one you don't understand the purpose of, rewriting GNU Autoconf in GNU make would serve no purpose since what Autoconf does has nothing to do with building, but rather finding out details about the running system. Maybe you were thinking of GNU Automake ...
Autotools in general, I guess. Detecting OS and features, conditionally including sources in the build, abstracting compiler flags. The most important feature though was automatically figuring out the list of source files in an arbitrary file system tree structure and then mapping them to the build tree as object and dependency files. I somehow conjured up a recursive wildcard function that implements a simple find command in pure GNU make. It's kind of horrifying now that I think about it.
I suppose I was rewriting automake too: I started metaprogramming GNU make by evaluating templates. It's a surprisingly lisplike turing tarpit.
Re: Things You Should Never Do, Part I (2000)
#85I first read this as a 22-year-old software engineer. Re-reading it as a 46-year-old CTO, it still tracks and still is truer than not. Most re-writes happen because the engineers want to, not because they really need to.
Not only that, it’s often an unconscious way for engineers to regain a sense of self-direction and autonomy. As folks have difficulty actually articulating that need as such, it can often be accomplished in much more productive ways that are not harmful to firms.
Do you have any examples of more productive alternatives?
Re: Things You Should Never Do, Part I (2000)
#86Earlier quoted context omitted.
I've read every line of a 300,000 line web application in less than a year working at a company. I doubt I could write that many lines of code in that amount of time.
What language do you use? In UI you can reach that 300k loc quite quickly.
PHP, so some of it was JS and some HTML
Re: Things You Should Never Do, Part I (2000)
#87Earlier quoted context omitted.
I've read every line of a 300,000 line web application in less than a year working at a company. I doubt I could write that many lines of code in that amount of time.
300,000 lines of code doesn't seem unattainable for a single developer in a year. If I'm in the zone, I can easily bang out 5-10k lines of code over a weekend if I know what I want to write. But that's the thing: a lot of development involves not writing any code, as you re-think your abstractions, plan the architecture of the next bits you'll write, debug what you've written, etc. So I don't think we're necessarily…
Surely you jest, nobody writes a full shopping platform by themselves in a year, yet I read it and deleted all the old code that we didn't need.
Re: Things You Should Never Do, Part I (2000)
#88A tool I wrote at a previous job was thrown out after a few years of everyday use within the team. The team lead had noticed that my 300 or so lines of code was unnecessarily complex and could be replaced by ten lines of $TEAM_LEADS_FAVORITE_LANGUAGE. So it was. Every few weeks someone came to me complaining that something didnt work in "my" tool. Thanks to git I could port the old, working code over to the new tool…
I once worked with a guy that probably would be classed as a 10x developer. Always when the discussion about an edge case came up, he'd dismiss it as "that's never gonna happen". The of course when those never-gonna-happen things happened, he would absolutely not want the responsibility to fix them.
It's easy to convince management you are brilliant by tackling the common cases of a problem and leaving the edge cases to someone else to solve further down the line.
Re: Things You Should Never Do, Part I (2000)
#89There is another fallacy that I believe Netscape fell into at the time.
Rewrites often have the goal of "this time we are making everything perfect".
Which leads to tons of unnecessary abstractions and endless design proposals.
For Netscape 6 it was the idea of introducing XPCOM. "Classes are stupid everything is an interface".
Which later led to the "DeCOMtamination" project.
Re: Things You Should Never Do, Part I (2000)
#90Earlier quoted context omitted.
Not only that, it’s often an unconscious way for engineers to regain a sense of self-direction and autonomy. As folks have difficulty actually articulating that need as such, it can often be accomplished in much more productive ways that are not harmful to firms.
Do you have any examples of more productive alternatives?
Not really. You have to begin by being able to be honest about the experience with yourself and decide what you want to do about it and if anything can be done.