Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical, cognitive, and intent debt

martinfowler.com

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Technical, cognitive, and intent debt

#81

Post by bandrami »

ah1508 wrote: post #17
kvisner wrote: post #15

Earlier quoted context omitted.

I agree, but that formal language doesn't need to be executable code.

So you need to find something better. In an article "How NASA writes 'perfect' software (1996) (fastcompany.com)" (comments on HN), the author explains that adding GPS support required 1500 pages of spec, and to avoid ambiguity the spec used pseudo code to describe expected features and behaviors. If you invent a formal language that is easy to read and easy to write, it may look like Python... Then someone will prob…

Not Python, it looked like Standard ML, and the interpreter is quite good

Re: Technical, cognitive, and intent debt

#82

Post by diehunde »

It's very nerve-racking for people who like to have a deep understanding of everything they ship. A modernization project that would take you 2 months now can be done in a week or less because you don't need to go deep into the business logic to replicate it and instead you can just focus on designing the boundaries and interfaces properly. Then like the article mentions, just create a good test harness to test parity as much as you can. I was feeling very conflicted about this myself, but then I thought: I have these other systems I have to maintain on a daily basis and I also don't understand the internals and business logic that well because I wrote them years ago and haven't changed much. I just rely on the test suite if something needs to be changed or the code structure if I need to see how something in particular works.

Re: Technical, cognitive, and intent debt

#83

Post by CharlieDigital » 

    > The most creative act is this continual weaving of names that reveal the structure of the solution that maps clearly to the problem we are trying to solve.
From Confucius, The Analects, 13.3:

    If names are not rectified, then language will not be in accord with truth.  If language is not in accord with truth, then things cannot be accomplished.  If things cannot be accomplished, then ceremonies and music will not flourish.

Re: Technical, cognitive, and intent debt

#84

Post by konovalov-nk »

russellthehippo wrote: post #80

Best thing I've read on hacker news in so long. I relate so hard. Simon Willison's stuff on cognitive debt and "your job is to ship code you have proven to work" have led me to work on a project about Intent-Driven Development, because prior intent always seemed to dim with each set of changes. Might put it together into a real protocol and post here on hacker news sometime.

I'm wondering if we're working on the same thing. If you haven't seen my posts I suggest to look through them.

In short:

1. stacked-commits automation (cannot skip writing context/why/verify sections)

2. product specs (full ERD: https://excalidraw.com/#json=WT-oRUdyKBhAsDZJ3NwAR,WAbVgfO39...)

3. linking specs to code via SCIP indexes, and commits to ACs, later you can attach anything you want

Re: Technical, cognitive, and intent debt

#85

Post by patrickmay »

destring wrote: post #73
kvisner wrote: post #2

I see what Martin is saying here, but you could make that argument for moving up the abstraction layers at any point. Assembly to Python creates a lot of Intent & Cognitive debt by his definition, because you didn't think through how to manipulate the bits on the hardware, you just allowed the interpereter to do it. My counter is that technical intent, in the way he is describing it, only exists because we needed to…

The thing is that you paid that debt once. The mappings are well defined and deterministic. The whole purpose of an abstractions is to not have to look underneath it to make sure what you did with the abstraction is still correct. You can make sure because you, or someone you trust, did the work of paying that debt once. With LLMs you always need to verify the output, for every generation you need to pay that debt. S…

Exactly, well said.

"The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." -- Edsger Dijkstra

Re: Technical, cognitive, and intent debt

#86

Post by chaosprint »

Well written. I also wrote in my personal notes yesterday that if you don't organically and continuously develop code, it's hard to say you truly "own" it.

Like self-driving cars, at least you remember the scenery along the way, but now it just teleports you to another place and then shows you the recording.

This kind of review is ineffective. Such ghosted code might be acceptable for small tools, but for databases or similar systems, it's really worrying.

I've now basically stopped granting the agent any write permissions and returned to how I wrote codes 2 years ago with manual QA. The thing is, it's actually more efficient in turns of tokens and the results.

That's just my personal experience.

Re: Technical, cognitive, and intent debt

#87

Post by plaguuuuuu »

awesome_dude wrote: post #19
marktani wrote: post #16

Earlier quoted context omitted.

I agree with your sentiment here. However: > if anything, by most traditional forms of evaluating software quality, the projects I work on are better than what they were 5, 10 years ago, using the same metrics as back then. In this side sentence you're introducing so much vagueness. Can you share insights to get some validation on your claim? What metrics are you using and how is your code from 10, 5, 0 years perform…

The anecdote the GP is providing there rings true for me too - although I'm not sure if I am going offer better detail. I'm a proponent of architectural styles like MVC, SOLID, hexagonal architecture, etc, and in pre-LLM workflows, "human laziness" often led to technical debt: a developer might lazily leak domain logic into a controller or skip writing an interface just to save time. The code I get the LLM to emit is…

I've recently had the interesting experience of working on a Clean Architecture project for the first time. Pre and post-LLM adoption.

It has been... difficult. Services/modules organised by infrastructural layer rather than by feature. A mediator pattern abstracted away the handling of commands. Just in case one day you needed CreateFooCommand to be executed by a different handler, or something, I dunno. It was so hard to figure out how to navigate everything. And it felt like the entire tradeoff was for the purpose of stopping smoothbrains from adding the ORM to an API endpoint - but with the cost of this crushing accidental complexity that made it hard for everyone to hold everything in their heads, not just for me but also for the smart guys on the team.

It turns out that the LLMs also performed extremely poorly. All the heavy abstractions were too hard for them (not to mention most of the developers).

I knew I had no chance of shifting things away from that paradigm. But as luck would have it... we started basically vibe-rewriting it from scratch without bullshit enterprisey crap and its (a) dead simple (b) has most of the features after one month (c) even though the code is questionable, inelegant AI slop, with nearly zero regard to proper architectural design, it's way easier to deal with than before

I've never felt so vindicated.

Re: Technical, cognitive, and intent debt

#88

Post by plaguuuuuu »

dc_giant wrote: post #14
hibikir wrote: post #6

LLMs don't lack the virtue of laziness: it has it if you want it to, by just having a base prompt that matches intent. I've had good success convincing claude backed agents to aim for minimal code changes, make deduplication passes, and basically every other reasonable "instinct" of a very senior dev. It's not knowledge that the models haven't integrated, but one that many don't have on their forefront with default s…

Mind sharing the instructions you give Claude to go for minimal code changes etc?

"Coding style should reflect the casual minimalism of expert programmers" used to to bump it up a bit, I guess it had the right activations or whatever, but I haven't bothered as much with this stuff with recent models cause (a) writing "You are a gigachad developer who is a Level 99 Staff Wizard at FAANG" doesn't work any more and (b) More or less they code like what they can see in their context; if you have a shit codebase you're going to get more shit, so theoretically I'd give a baseline coding style in some instructions, but realistically I haven't have enough motivation to bother with the last thingy I was working on.

Re: Technical, cognitive, and intent debt

#89

Post by lucketone »

diehunde wrote: post #82

It's very nerve-racking for people who like to have a deep understanding of everything they ship. A modernization project that would take you 2 months now can be done in a week or less because you don't need to go deep into the business logic to replicate it and instead you can just focus on designing the boundaries and interfaces properly. Then like the article mentions, just create a good test harness to test parit…

To have good test harness you need to get deep into business logic. Am I missing something?

Re: Technical, cognitive, and intent debt

#90

Post by yasirlatif »

The "intent debt" framing is the most underappreciated category here. Cognitive and technical debt are at least visible in the code. Intent debt is invisible — it only surfaces when someone makes a change that's locally reasonable but globally wrong because the original constraint no longer exists in any artifact. The hardest version of this is in enterprise systems where the constraint was a regulatory requirement that quietly changed three years ago, but nobody updated the code because the tests still passed. You can't recover intent from a test suite.
Post reply on HN