Preferences

Software engineers, I love yall. To see the light at the end of the tunnel. To see some glorious perfect paradigm that maybe could be. I envy you.

I grew up in a datacenter. Leaky air conditioners and diesel generators. Open the big doors if it gets too hot.

   Now let’s go back. Back to when we didn’t know better.
   Software doesn’t stay solved. Every solution you write starts to rot the moment it exists.
Everything, everywhere, is greasy and lousy and half broken. Sysadmins, we accept that everything is shit from the very beginning.

bonoboTP
This is quite hard to grapple with fresh out of school, where you worked mainly on pristine implementations of eternal algorithms, proven to be optimal in multiple ways, elegantly crafting each loop and feeling accomplished by expressing the algo with even higher clarity, reading and idealizing Knuth etc.

Then you see the real world and you think it must be because people are stupid, the bosses are pointy-haired, they don't understand, they don't value elegance, they are greedy, they etc. etc. But once you spend enough time on your own projects, and they evolve and change over the years, they turn more and more into a mess, you rewrite, you prioritize, you abandon, you revive, and you notice that it goes much deeper than simply laziness. Real solutions depend on context, one caching algo is good when one medium is x times faster than another, but not when it's only y times faster. It makes sense to show a progress bar when downloading a file if the usual internet speed is X but not when it's Y. Over years and decades the context can shift, and even those things can change that were only silent assumptions of yours when you made the "perfect" program as a young'un, looking down on all the existing "messy" solutions that do a bunch of unnecessary cruft. It's an endless cycle...

> Software doesn’t stay solved. Every solution you write starts to rot the moment it exists.

I don't really agree with this. Yes, it gets outdated quickly and breaks often if you build it in such a way that it relies on many external services.

Stuff like relying on "number-is-odd" NPM package instead of copy-pasting the code or implementing it yourself. The more dependencies you have, the more likely it will break.

If your software works locally, without requiring an internet connection, it will work almost forever.

Now, if you want to keep developing the software and build it over a long period, the secret is to always keep all dependencies up-to-date. Is there a ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.

Phlebsy
To me the point of the saying is more that the assumptions and environment that the software was written with are almost always going to change. Meaning the business and requirements rather than the technical implementation choices. Software doesn't exist in a vacuum, but rather to solve a certain set of business requirements that have the potential to shift out from under you depending on the industry, legislation, and your leadership. The things that you have negligible control or foresight over, rather than knowing that there's going to be another major framework update next quarter.

There are certainly horizontal slices of every stack that can be written to remain stable regardless of the direction the business takes, but those are rarely the revenue drivers that the business cares about beyond how much they have the potential to cause instability.

I remember when Turbo Pascal 7.0 programs started failing with Division by 0 error cause Turbo Pascal runtime does calibration loop at the start to calculate how many no-ops to sleep for 1 millisecond.

So - your HelloWorld written 10 years ago suddenly stopped working after CPU you run it on got too fast.

Yes, if you change hardware, the software can break (a lot less often now than before though, as hardware changes are a negligible and they usually think about backwards compatibility).
I'm not sure if it's more or less often now, but over decades almost everything breaks one way or another.

Even if your code, OS and hardware had no bugs and was designed perfectly and you keep the same hardware to run you code forever - there's layers under the hardware - the reality outside the computer.

You have written perfectly secure website. Then quantum computers happen.

Countries are created and fall apart. People switch writing systems and currencies. Calendars get updated.

Your code might technically work after 100 years, but with almost 100% probability it won't be useful for anything.

That's most probable to happen, but there are still example of hardrware/devices created many years ago that function exactly the same.

If you take a Tamagotchi device from 30 years ago, it will likely still work as well as it did when it was released.

> a lot less often now than before though

Someone is not familiar with iOS/macOS/Android, where stuff breaks every. effing. year. Windows is the exception, nowadays.

int_19h
I remember that bug. I also remember that there were generic patchers that could fix any random .exe compiled with Turbo Pascal without even having to recompile it.
chamomeal
That sorta supports the point the article was making though:

> ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.

Is, to me, almost the same sentence as

> Every solution you write starts to rot the moment it exists

I mentioned updating is only necessary if you plan to keep developing the software.

If you build it once, and the existing functionality is enough (no plans to add extra features ever again), then you can remove all external dependencies and make it self-contained, in which case it will be very unlikely to break in any way.

As for the security aspects of not updating, with the proper setup, firewall rules and data sanitization, it should be as secure 10 years later as any recently developed software.

0x1ceb00da
> Every solution you write starts to rot the moment it exists

Not if you work on temple os.

galbar
I have said many times to teammates: the only code that is perfect is the one that hasn't left our minds. The moment it's written down it becomes flawed and imperfect.

This doesn't mean we shouldn't try to make it as good as we can, but rather that we must accept that the outcome will be flawed and that, despite our best intentions, it will show its sharp edges the next time we come to work on it.

moffkalast
I'm sure some mathematicians would disagree.
bonoboTP
Math can be greasy and messy. Definitions can be clumsy in a way that makes stating theorems cumbersome, the axioms may be unintuitive, proofs can be ugly, they can even contain bugs in published form. There can be annoying inconsistencies like optional constant factors in Fourier, or JPL quaternions.

Yes, prototypical school stuff like Pythagoras are "eternal" but a lot of math is designed, and can be ergonomic or not. Better notation can suggest solutions to unsolved problems. Clumsy axioms can hide elegant structure.

I think applied mathematicians started to encounter this reality of the impure world the first time someone taped a dead moth into the logbook of the Harvard Mark II.
gnawing_termite
your comment made me think of a passage in Italo Calvino's Invisible Cities:

Kublai Khan does not necessarily believe everything Marco Polo says when he describes the cities visited on his expeditions, but the emperor of the Tartars does continue listening to the young Venetian with greater attention and curiosity than he shows any other messenger or explorer of his. In the lives of emperors there is a moment which follows pride in the boundless extension of the territories we have conquered, and the melancholy and relief of knowing we shall soon give up any thought of knowing and understanding them. There is a sense of emptiness that comes over us at evening, with the odor of the elephants after the rain and the sandalwood ashes growing cold in the braziers, a dizziness that makes rivers and mountains tremble on the fallow curves of lhe planispheres where they are portrayed, and rolls up, one after the other, the despatches announcing to us the collapse of the last enemy troops, from defeat to defeat, and flakes the wax of the seals of obscure kings who beseech our armies' protection, offering in exchange annual tributes of precious metals, tanned hides, and tortoise shell. It is the desperate moment when we discover that this empire, which had seemed to us the sum of all wonders, is an endless, formless ruin, that corruption's gangrene has spread too far to be healed by our scepter, that the triumph over enemy sovereigns has made us the heirs of their long undoing. Only in Marco Polo's accounts was Kublai Khan able to discern, through the walls and towers destined to crumble, the tracery of a pattern so subtle it could escape the termites' gnawing.

This item has no comments currently.