Comment by datadrivenangel
12 hours ago
"There's plenty of space for "disposable and single use software." Sure, to a trained software engineer, this might be "bad code" but doing today's task has value, even if the code that performs that task isn't "accretive.""
Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.
> Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.
Well, It's really early in the morning and I've got the quote of the day already
live, laugh, cruft
Though I walk through the valley of technical debt I shall fear no eval
This is a slightly modified version of the serenity prayer of AA fame.
Yes, I know, but I substituted that one in daily usage for just shouting "SERENITY NOW" at maximum volume.
2 replies →
Part of why I like "tech debt" as a term. Much like actual financial debts, some tech debt has a low enough interest rate or is easy enough to declare bankruptcy on that it's not worth paying off.
That quote also resonated with me. It reminded me of "Perl, the write-only language"-meme of yore.
And I think there is a place for perl, just like there is a place for bash one-liners.
The authors example is personal software. The things we write to scratch our own little itches, that do not need to be shared or developed together with other people.
The real trick is recognizing when "disposable" code has quietly become infrastructure
Law of disposable infrastructure: The more temporary a fix is intended to be, the more likely it is to become load-bearing permanent infrastructure
Exactly THIS!
I found an excellent way to avoid premature abstraction and optimization and to write better software in general was to explicitly consider v1.x a throw-away.
Build something expedient that works well enough to deploy in the field, get actual user feedback and system metrics (e.g., where are the actual bottlenecks). Do a few iterations on user feedback and system metrics. NOW, you are much further down the road to a true final spec, and you can use that real information to design the real system to scale up on.
One Test Is Worth A Thousand Opinions.
This plan first tests your ideas against the real world of users, hardware, and data flows, and keeps a lot of technical debt out of the scaling system.
I discovered it a bit by accident, having previously been really big on early abstraction and planning, but sort of having to do this in one startup, and it was a real eye-opener how well it worked.
>>> Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.
Fantastic
We used to keep it in it's own separate thing: Microsoft Excel.