One of the things I wish this article highlighted more is the impact of team churn.
Even with the generous assumption of five year service life for a website, I think that average tenure at a company now is down below something like two years.
In such an environment, you really are best off just writing simple, disposable, easily tweaked code instead of trying to do things as beautifully as possible.
Ablative coding is a whole interesting topic in and of itself.
I’ve certainly done my share of hand-wringing about the long-term impact on the industry of constant job hopping, chiefly the possibility that it will lead to an industry full of people who have never seen their own code become the legacy ball of mud everyone hates to touch.
But maybe there’s a local maximum to shoot for: treating “fully maintainable by a team where nobody has more than a year of experience with the code base” as a first-class design goal, something that we’d be willing to trade away other meaningful goals for. (Today, I think maintainability is often first on the chopping block when it conflicts with other goals.)
What that looks like in practice, I don’t know. In some ways, maybe not too different from what top-flight teams already do: great automated tests, thorough documentation, strong modularity, and well-oiled onboarding processes. But in other ways, maybe pretty different: perhaps you would want to steer well clear of any tools or libraries or frameworks that require deep knowledge, even at the cost of significant developer productivity.
perhaps you would want to steer well clear of any tools or libraries or frameworks that require deep knowledge, even at the cost of significant developer productivity.
Highlighting this point because it’s incredibly important.
Consider the difference in max productivity afforded by using, say, Go instead of Ruby or Closure or Haskell. Sure, your best developers are going to be more productive in the “better” languages, but your average developer will see little of that benefit and might go off the rails instead.
Another thing to consider is the trade-off between readability & “writability”. Very powerful languages that allow a lot of abstraction can allow programmers to be very efficient/concise when writing new code but then newcomers to the codebase have a steep learning curve when they need to read that code later.
The article concludes that designing for short lifetimes is usually the right call because requirements will change so much as to render the initial decisions incorrect or irrelevant before a site has gotten very old.
In my professional work, this has absolutely been the case. Sometimes the requirements change so much as to render the technical decisions incorrect before the website has even launched!
But in my personal hobby projects, this has definitely not been the case. I ran a hobby site in the 1990s that became popular in a particular niche, and it is still receiving a modest but regular flow of visitors today. 100% static content, with HTML files generated from awful hand-rolled templates by some simple Python scripts. Aside from moving it to a new hosting provider because my original one went out of business, I haven’t touched it at all in probably 15 years. It looks totally low-tech by today’s standards, but it’s good enough for what it is. Maybe I’ll have to port my scripts to Python 3 at some point, but other than that, I fully expect it to outlive me without any real maintenance or attention on my part.
I’d never stopped to consider it before, but in a way it’s kind of ironic that the stuff I get paid very generous amounts of money to create all gets thrown away within a few years, whereas the stuff I was screwing around with on weekends to amuse myself will probably still have an occasional user or two long after I’m gone.
they won’t be stuck with what they’ve built for all that long
I agree but not for the same reason. They won’t be stuck because the devs creating projects typically leave it after a year or 2 and then someone else comes in and is stuck with it, for a year or 2, and then repeat.
Devs aren’t choosing tools for long term maintenance because they either a) only build greenfield and aren’t stuck with it or b) they get stuck with the project after it’s built and aren’t given the power to change things.
Devs are choosing tools for quick Greenfield spin up because that’s what we market to each other. The number of taglines on most tools about “only N lines of code” or “deployed in N mins” with zero regard to what happens a year or 2 later because supposedly we’ll just rebuild it with the next hot tool.
One of the things I wish this article highlighted more is the impact of team churn.
Even with the generous assumption of five year service life for a website, I think that average tenure at a company now is down below something like two years.
In such an environment, you really are best off just writing simple, disposable, easily tweaked code instead of trying to do things as beautifully as possible.
Ablative coding is a whole interesting topic in and of itself.
This is a great point.
I’ve certainly done my share of hand-wringing about the long-term impact on the industry of constant job hopping, chiefly the possibility that it will lead to an industry full of people who have never seen their own code become the legacy ball of mud everyone hates to touch.
But maybe there’s a local maximum to shoot for: treating “fully maintainable by a team where nobody has more than a year of experience with the code base” as a first-class design goal, something that we’d be willing to trade away other meaningful goals for. (Today, I think maintainability is often first on the chopping block when it conflicts with other goals.)
What that looks like in practice, I don’t know. In some ways, maybe not too different from what top-flight teams already do: great automated tests, thorough documentation, strong modularity, and well-oiled onboarding processes. But in other ways, maybe pretty different: perhaps you would want to steer well clear of any tools or libraries or frameworks that require deep knowledge, even at the cost of significant developer productivity.
Highlighting this point because it’s incredibly important.
Consider the difference in max productivity afforded by using, say, Go instead of Ruby or Closure or Haskell. Sure, your best developers are going to be more productive in the “better” languages, but your average developer will see little of that benefit and might go off the rails instead.
Another thing to consider is the trade-off between readability & “writability”. Very powerful languages that allow a lot of abstraction can allow programmers to be very efficient/concise when writing new code but then newcomers to the codebase have a steep learning curve when they need to read that code later.
The article concludes that designing for short lifetimes is usually the right call because requirements will change so much as to render the initial decisions incorrect or irrelevant before a site has gotten very old.
In my professional work, this has absolutely been the case. Sometimes the requirements change so much as to render the technical decisions incorrect before the website has even launched!
But in my personal hobby projects, this has definitely not been the case. I ran a hobby site in the 1990s that became popular in a particular niche, and it is still receiving a modest but regular flow of visitors today. 100% static content, with HTML files generated from awful hand-rolled templates by some simple Python scripts. Aside from moving it to a new hosting provider because my original one went out of business, I haven’t touched it at all in probably 15 years. It looks totally low-tech by today’s standards, but it’s good enough for what it is. Maybe I’ll have to port my scripts to Python 3 at some point, but other than that, I fully expect it to outlive me without any real maintenance or attention on my part.
I’d never stopped to consider it before, but in a way it’s kind of ironic that the stuff I get paid very generous amounts of money to create all gets thrown away within a few years, whereas the stuff I was screwing around with on weekends to amuse myself will probably still have an occasional user or two long after I’m gone.
I agree but not for the same reason. They won’t be stuck because the devs creating projects typically leave it after a year or 2 and then someone else comes in and is stuck with it, for a year or 2, and then repeat.
Devs aren’t choosing tools for long term maintenance because they either a) only build greenfield and aren’t stuck with it or b) they get stuck with the project after it’s built and aren’t given the power to change things.
Devs are choosing tools for quick Greenfield spin up because that’s what we market to each other. The number of taglines on most tools about “only N lines of code” or “deployed in N mins” with zero regard to what happens a year or 2 later because supposedly we’ll just rebuild it with the next hot tool.