I posted an idea on twitter a while back that I wanted to keep in the Intertubes, which is one of the reasons that I don’t delete my old twitter account. Then I realized I could post it here instead of tediously moving it to every new “social” platform every time the current one burns down.
This is the idea:
Idea: Slow Code … a non-profit dedicated to the idea of improving the software world by taking more time to write less code.
Here is a screen shot of it to capture the time stamp:
As a useless digression, another idea that I posted on twitter first was about the fog. So here is a screen shot of that to capture that timestamp:
Maybe soon I’ll be able to delete the twitter after I carefully move all the screen shots here.
Anyway, the idea in slow code is, of course, stolen from the idea behind Slow Food. The main purpose of Slow Food is, to a first approximation, to apply this same idea to food. That is, a way to treat food that in a way that pays due respect to the origins and history of the dishes rather than just to how much of it you can sell at a profit.
Replace food with code and poof you have slow code.
To me the remarkable thing is that the through line from food to code is pretty direct. Scaling food operations to be large scale profit centers distorts the product, often making it worse. Similarly, the realities of making money from software, in many ways, makes software worse.
What we have learned in the 50 or so years that large companies have driven industrial growth from software development is that no matter what you might think, and what your users might tell you, at a large scale the only thing users will actually pay money for in the long term is new features. They might protest to the high heavens that all they want is new releases to make what is already there work better, but the evidence and their behavior indicates exactly the opposite. There has to be at least the appearance of constant forward evolution in order for a software product to continue to generate more revenue. Software that has reached a stable state over a long period of time, and is thus more reliable and dependable, is also a financial loser.
But there is even more to it. In order to keep people interested the cadence for new things in a software product has to be short enough. Back in the day cycles of multiple years for large products were not unheard of. These days though you need to do at least one big release per year and then multiple small releases per year in order to keep the train moving.
You see this across the entire landscape of software products. It’s a constant grind to make the product look “new”. The resulting pressure to create new features and keep up with the evolution of your infrastructure leaves very little time for bug fixing, stability improvements or any kind of general contemplation and refinement.
So I’d like there to be a way to slow this down and give everyone time to take a breather and spend some time thinking and fixing things. This will improve the lives of programmers because they can gain some piece of mind and escape an almost constant pressure for releases. In theory it should also make life better for users because it would give programmers time to fix those long standing annoying bugs that always fall by the wayside when they are forced to do nothing but build new things. Maybe users can be made to understand this. Maybe not.
It would be nice to have more time for these things sometimes though. Perhaps this is an unrealistic ideal. But ah well. It’s a good idea anyway.