It concerns itself with the adjacent systems that are receiving data from the same upstream processes and/or emitting data to the same downstream processes the system is emitting to.
"Writing code" is about making code that *runs well*. "Software engineering" is about making code that *fails well*.
7/
I've been saying exactly this for years. The concept of "technical debt" is absurd without the complementary idea of "code is a liability". One does not make interest payments on and pay down the principle of an asset, but instead one does this on a liability.
Code is a mortgage against future need to make changes to support the same and new use cases.
Think of it this way: One doesn't fix bugs, one merely replaces found bugs with more subtle and hopefully more harmless ones. Bugs are, themselves, risk. They exist in the code, thus making the code itself a liability.
@pluralistic thinking about that old project management jokes about how many monkeys it takes to write code… or how 9 pregnant women can make a baby in one month. Bean counting as a form of #projectmanagement 🙄
@wb2ifs @pluralistic And 36 pregnant women pop out the first baby after one week, right?
Seriously, 36 pregnant women, with 9 months of startup time, interleaved correctly, treated by unethical doctors with unethical drugs (or just surgical deliveries), can start producing one baby per week.
And our fascist billionaires see nothing wrong with playing eugenics like that.
@pluralistic lol it’s all slop, to get more slop in different forms, visit my website!
@pluralistic Just look around any companies network that has been around 10-20 years. Most likely you will find things like, Server 2008 machines, CentOS 5 machines, still on the network because they run some missionary critical software that no one has figured out how to move onto modern OS's.
@Lightfighter @pluralistic When I interviewed at Comcast (BIG mistake, but my subconscious saved me), they had me take a test to debug issues on a CentOS 5 VM. Even though it was 7 years ago and before IBM bought Redhat, it was still old.
@pluralistic are test cases liabilities? I don't think all code is equal in this sort of thing. If it's cranking out code you don't ship, it's not the same as generating bugs and shoving them to prod.
I was recently hired to rescue a coding project. The code base was so untenable it was a huge effort. The logic of what it was actually doing wasn't complex, but the code implementing it was so disparate you couldn't follow it. And there was so much repeated code, I couldn't understand why they didn't pull out the repeated logic into reusable functions.
I later thought, wait, this is A.I. It looked like small bits of generated code added on top of each other ad hoc.
"One of my most productive days was throwing away 1000 lines of code."
Managers are addicted to using the available tools rather than those they need, and then because they have a tool refuse to think about what they really need. Measuring software quality by lines is the same as looking for your keys under a lamppost rather than where you dropped them. 🤷
@electropict @phaedr0s @pluralistic Not addicted to – limited to. Executives are addicted to it, but managers suffer the consequences.
(source: Me. An ex-manager.)
@wcbdata @electropict @phaedr0s @pluralistic one of my old bosses said that working in corporate America is like being a lab rat in a cage. You press the green button and you’re rewarded with food. Press the red button and you get an electric shock ⚡️. But once you’re promoted to a new cage you discover that both buttons are broken. You keep getting shocked and the food doesn’t come.
@phaedr0s @pluralistic When I was employed by a certain large company, we needed a feature in our applications that wasn't provided by the OS, so I had to implement it in the app(s).
The next OS had the feature, but we still had to support older OSes. So on the day we ended support for that old OS, I gleefully deleted 7000 lines of code that took me months to write. Best day ever.
The only code with no bugs is code that doesn't exist.
Same here: after being dragged kicking and screaming to SQL, I was very happy to retire an Excel spreadsheet with 3000 lines of VBA. 45 minute reports cut to 30 seconds.
Friend who has a concrete pouring biz says "There are two kinds of concrete--the one that has cracked, and the other is the one that hasn't cracked yet."
@FallsMom @ben @phaedr0s @pluralistic They're not wrong.
@FallsMom @phaedr0s @pluralistic See also "There are two kinds of people. Those who have lost data, and those who are going to lose data."
@ben @FallsMom @phaedr0s @pluralistic Also, there are two kinds of people:
1) Those that can extrapolate from incomplete data,
@FallsMom @ben @phaedr0s @pluralistic
Underwriters successfully selling cyber insurance: “There’s only two kinds of companies, those that have been hacked, and those that don’t know it, yet.”
@pluralistic of course, Corey, that makes vast quantitites of "mission" critical lines of code "liabilities." Hundreds of billions of lines of production #COBOL code for example.
But that's a glib misdirction. Lines of code, human or AI generated, that are in production are both a liability and a responsibility. So if you promote slop or carefully engineered code, you own it and it owns you.
@pluralistic Because business majors are dumb, especially at the top schools, the suits all approach tech like they're running a factory that makes the known product at scale, not like they're building a custom skyscraper that requires custom engineering and can't just be "worked" at like an existing factory floor that produces a known thing. Effectively every tech project that isn't a small business tyrant overpaying to not just whitelabel is the architecture case, not the factory one, however.
@Emerson61 @pluralistic the whole business mentality is "what if everything was a widget factory because it made line go up" even when it doesn't work
@pluralistic The root cause of this problem is the stock market. If we are ever going to fix what you call enshittification, the stock market is going to have to be drastically reformed.
Companies are not being managed to maximize their operating profit. We'd be a whole lot better off if they were. They are being managed to maximize stock price, and the problem with that is you can sell and not own the consequences.
On the principle of "if I think of it, somebody much smarther than I has probably thought of it," I'm now imagining a graphical model of this kind of interface, rendered tomographical-like, in the way that geologists visualize geological structures...?
The digital archeology from "A Fire Upon the Deep" is going to be a thing way faster than I expected.
@Bandersnatch @pluralistic in our case "A Fire Upon The Creeps."
much like most pharmacists feel about drugs (useful if absolutely necessary but the less of them you take the better), coding is about having the least possible code to do what you want to accomplish.
in both cases, the more unnecessary stuff you have, the more likely the odd interactions and unpredictably overwhelm the usefulness.
The tech lead on my first job once told me to send him any changes deleting code for review, the more code deleted the better because he loves to see them
They never read mythical man month, didn’t they?
What was the line I heard recently that if a statistic and a measurement becomes a goal, it ceases to be meaningful.
Everybody who’s written more than 15 lines of code begins to understand that line count is not a measure of anything useful.
Code is a set of instructions for a machine to do something but even more important it’s documenting what people wanted to accomplish
@GhostOnTheHalfShell Well that sent me down a rabbit hole! I hadn't heard of Frederick Brooks nor the Mythical Man-Month. Looks worthwhile. Adding some of his writing to my reading list.
@GhostOnTheHalfShell @pluralistic And yet, programmers continue to be measured by how many lines of code they produce and how many bugs they fix. Part of the reason I left software development and never looked back.
I wonder which Forth developer notched up the most capabilities per byte.
Shoveling asbestos into the walls might be an understatement, AI looks more like microplastics we're spreading everywhere, including in our brains.
Since it has to be serviced with AI, slop code is an adjustable rate liability.
The cost to use AI changes, it's possible to get into a three lost decades situation like Japan, if a lot of debt is accumulated quickly and the rate then changes unfavorably.
@pluralistic 🎯The proof of the pudding is in the eating. Just “vibe code” a non trivial application and monitor the time you need to get your application *reliably* working. You will be AI coding cured for the rest of your career.
@pluralistic Somebody finally invented "Tech Debt as a Service”.
@angusm @pluralistic "Tech debt as a service" is my new all-time favorite description of vibe coding.
Thank you.
#Coding #DevOps #developers
Code is a liability. Code's *capabilities* are assets. The goal of a tech shop is to have code whose capabilities generate more revenue than the costs associated with keeping that code running. For a long time, firms have nurtured a false belief that code costs less to run over time: after an initial shakedown period in which the bugs in the code are found and addressed, code ceases to need meaningful maintenance.
2/
@pluralistic Sing it brother CODE IS A LIABILITY!
After all, code is a machine without moving parts - it does not wear out; it doesn't even wear down.
This is the thesis of Paul Mason's 2015 book *Postcapitalism*, a book that has aged remarkably poorly (though not, perhaps, as poorly as Mason's own political credibility): code is not an infinitely reproducible machine that requires no labor inputs to operate.
3/
Rather, it is a brittle machine that requires increasingly heroic measures to keep it in good working order, and which eventually does "wear out" (in the sense of needing a top-to-bottom refactoring).
To understand why code is a liability, you have to understand the difference between "writing code" and "software engineering."
4/
"Writing code" is an incredibly useful, fun, and engrossing pastime. It involves breaking down complex tasks into discrete steps that are so precisely described that a computer can reliably perform them, and optimising that performance by finding clever ways of minimizing the demands the code puts on the computer's resources, such as RAM and processor cycles.
5/
@pluralistic YES THIS ❤️❤️❤️
Meanwhile, "software engineering" is a discipline that subsumes "writing code," but with a focus on the long-term operations of the *system* the code is part of. Software engineering concerns itself with the upstream processes that generate the data the system receives. It concerns itself with the downstream processes that the system emits processed information to.
6/
It concerns itself with the adjacent systems that are receiving data from the same upstream processes and/or emitting data to the same downstream processes the system is emitting to.
"Writing code" is about making code that *runs well*. "Software engineering" is about making code that *fails well*.
7/
