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

They lied to you. Building software is hard

blog.nordcraft.com

Post reply on HN
Print view View original

71–80 of 119 posts

Re: They lied to you. Building software is hard

#71

Post by CuriouslyC »

adam_arthur wrote: post #51

LLMs have clearly accelerated development for the most skilled developers. Particularly when the human acts as the router/architect. However, I've found Claude Code and Co only really work well for bootstrapping projects. If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use. It will probably change once the appro…

Valknut is pretty good at forcing agents to build more maintainable codebases. It helps them dry out code, separate concerns cohesively and organize complexity. https://github.com/sibyllinesoft/valknut

Re: They lied to you. Building software is hard

#72

Post by etamponi »

raincole wrote: post #59
mlsu wrote: post #53

Fred Brooks, from "No Silver Bullet" (1986) > All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivit…

I think software was indeed 9/10 accidental activities before AI. Probably still mostly accidental activities with the current LLM. The essence: query all the users within a certain area and do it as fast as possible The accident: spending an hour to survey spatial tree library, another hour debating whether to make our own, one more hour reading the algorithm, a few hours to code it, a few days to test and debug it…

It that's the essence, then of course 9/10 is accident. I think that's not software engineering though.

The essence: I need to make this software meet all the current requirements while making it easy to modify in the future.

The accident: ?

Said another way: everyone agrees that LLMs make it very easy to build throw away code and prototypes. I could build these kind of things when I was 15, when I still was on a 56k internet connection and I only knew a bit of C and html. But that's not what software engineers (even junior software engineers) need to do.

Re: They lied to you. Building software is hard

#73

Post by adam_arthur »

lowbloodsugar wrote: post #63
adam_arthur wrote: post #51

LLMs have clearly accelerated development for the most skilled developers. Particularly when the human acts as the router/architect. However, I've found Claude Code and Co only really work well for bootstrapping projects. If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use. It will probably change once the appro…

>If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use. Worse, as its planning the next change, it's reading all this bad code that it wrote before, but now that bad code is blessed input . It writes more of it, and instructions to use a better approach are outweighed by the "evidence". Also, it's not tech debt: h…

People can take on debt for all sorts of things. To go on vacation, to gamble.

Debt doesn't imply it's productively borrowed or intelligently used. Or even knowingly accrued.

So given that the term technical debt has historically been used, it seems the most appropriate descriptor.

If you write a large amount of terrible code and end up with a money producing product, you owe that debt back. It will hinder your business or even lead to its collapse. If it were quantified in accounting terms, it would be a liability (though the sum of the parts could still be net positive)

Most "technical debt" is not buying the code author anything and is materialized through negligence rather than intelligently accepting a tradeoff

Re: They lied to you. Building software is hard

#74

Post by idle_zealot »

raincole wrote: post #59
mlsu wrote: post #53

Fred Brooks, from "No Silver Bullet" (1986) > All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivit…

I think software was indeed 9/10 accidental activities before AI. Probably still mostly accidental activities with the current LLM. The essence: query all the users within a certain area and do it as fast as possible The accident: spending an hour to survey spatial tree library, another hour debating whether to make our own, one more hour reading the algorithm, a few hours to code it, a few days to test and debug it…

Isn't the solution to that standardizing on good-enough implementations of common data structures, algorithms, patterns, etc? Then those shared implementations can be audited, iteratively improved, critiqued, etc. For most cases, actual application code should probably be a small core of businesses logic gluing together a robust set of collectively developed libraries.

What the LLM-driven approach does is basically the same thing, but with a lossy compression of the software commons. Surely having a standard geospatial library is vastly preferable to each and every application generating its own implementation?

Re: They lied to you. Building software is hard

#75

Post by commandlinefan »

citelao wrote: post #15

Perhaps this is a bit OT, since the article focuses more on self-development ("When training a muscle, you only get stronger with resistance"), but I wonder about the subtitle: > Every week there seems to be a new tool that promises to let anyone build applications 10x faster. The promise is always the same and so is the outcome. Is the second sentence true? Regardless of AI, I think that programming (game developmen…

> programming is easier than ever

Or does it just seem that way because you've had a whole lifetime to digest it one little bit at a time so that it all seems intuitive now? If "easy to understand and get started with" were the bar for programming capability, we'd have stopped with COBOL.

Re: They lied to you. Building software is hard

#76

Post by themafia »

adam_arthur wrote: post #51

LLMs have clearly accelerated development for the most skilled developers. Particularly when the human acts as the router/architect. However, I've found Claude Code and Co only really work well for bootstrapping projects. If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use. It will probably change once the appro…

> accrue massive technical debt

The primary difference between a programmer and an engineer.

Re: They lied to you. Building software is hard

#77

Post by etamponi »

zkmon wrote: post #54

> With no-code tools you often reach a hard limit where the tool simply does not make sense to use anymore. No-code is the same trend that has abstracted out all the generic stuff into infrastructure layers, letting the developers to focus on Lambda functions, while everything in the lower levels is config-driven. This was happening all the time, pushing the developer to easier higher layers and absorbing all complex…

The point of the article is that the jump start that AI gives you is not the same as the one that well thought frameworks give you. What AI writes falls apart and leaves you with the ruins.

Re: They lied to you. Building software is hard

#78

Post by lowbloodsugar »

vineethy wrote: post #66

strongly disagree with this article. I think using the tools can actually directly lead to a junior engineer getting closer to a senior engineer. Telling junior engineers that they have to get better at typing out code in order to be better engineers misses what actually makes someone a better engineer. It's worth actually being specific about what differentiates a junior engineer from a senior engineer. There's two…

What comes to mind is Java vs assembly. Claude is just a really really high level language compiler. I work with senior Java devs who have never written assembly.

On the learning front, I spend the weekend asking Claude questions about Rust, and then getting it to write code that achieved the result I wanted. I also now have a much better understanding of the different options because I've gotten three different working examples and gotten to tinker with them. It's a lot faster to learn how an engine works when you have a working engine on a dyno than when you have no engine. Claude built me a diesel, a gasoline and an electric engine and then I took them apart.

Re: They lied to you. Building software is hard

#79

Post by themafia »

1970-01-01 wrote: post #3

We have hard evidence of it becoming easier every damn day. AI is taking these jobs. The models aren't perfect, but the speed tradeoff is so massive that you really can't say it's "hard" to build anything anymore. Nobody is lying.

> but the speed tradeoff

If you only care about a single metric you can convince yourself to make all kinds of bad decisions.

> Nobody is lying.

Nobody is being honest either. That happens all the time.

Re: They lied to you. Building software is hard

#80

Post by hn_throwaway_99 »

gdubs wrote: post #48

One of my all-time favorite quotes is from Zen Mind, Beginner's Mind and it goes: “In the beginner’s mind there are many possibilities, but in the expert’s there are few.” There's such a wide divergence of experience with these tools. Often times people will say that anyone finding incredible value in them must not be very good. Or that they fall down when you get deep enough into a project. I think the reality is th…

I definitely agree with this. Older folks have to deal with the double whammy of being familiar with what they already know, plus there is a good bit of research that learning and absorbing new things just gets harder past mid-40s or so.

That said, I don't think this negates what TFA is trying to say. The difficulty with software has always been around focusing on the details while still keeping the overall system in mind, and that's just a hard thing to do. AI may certainly make some steps go faster but it doesn't change that much about what makes software hard in the first place. For example, even before AI, I would get really frustrated with product managers a lot. Some rare gems were absolutely awesome and worth their weight in gold, but many of them just never were willing to go to the details and minutiae that's really necessary to get the product right. With software engineers, if you don't focus on the details the software often just flat out doesn't work, so it forces you to go to that level (and I find that non-detail oriented programmers tend to leave the profession pretty quickly). But I've seen more that a few situations where product managers manage to skate by without getting to the depth necessary.

Post reply on HN