undefined | Better HN

0 pointsaa-jv8h ago0 comments

Its kind of astonishing to see years of traditional software engineering practices being tossed aside in the rush for the Latest Cool New Thing™ ... have people really forgotten that you have to apply a workflow to software development, in order to have quality software?

You don't just write it, compile it, run it and ship it - do you? Surely, in the rush to become as agile as possible, folks haven't forgotten their quality checks in the workflow/process?

I have had great success with AI coding these days .. but I treat the agents as if they were junior developers capable of doing any dumb thing I ask them to, no matter how dumb it is. They, therefore, must be treated as junior devs - every line of code has to be reviewed. Every assumption about the specifications and requirements has to be checked against actual code, and against the original specifications and requirements.

What I see these days, is a lot of antsy kids who wanted to 100% ignore the wisdom of their elders, rushing into the maw of AI, and wondering why everyone is getting chewed up. Its pretty simple: AI-based software development is just another manifestation of software development, except that it requires even more rigorous quality steps in your workflow. So, if you were not rigorous before AI, you're going to get burned fingers - no doubt about it. Fix the rigor, people.

If you're not placing your AI buddy on a workflow that has "Specs->Reqs->Design->Analysis->Implementation->Review->Integration->Release" somewhere in the bag of worms, you're .. doing software wrong. You cannot just ignore natural laws and assume, because you 'know better', your software will 'be better'. And whether we like it or not, all software follows a philosophically natural law, which has evolved to become better understood, and thus more broadly applicable, over decades of human attention. Ignoring these natural laws in order to be a bleeding edge AI cowboy is only gonna get you butt-hurt, kiddo. Learn proper software management techniques first, AI second. Always. AI is just another junior dev - if your workflow is bogus, it doesn't matter how many dev's you've got. Period. You're going to be shipping crud.

It doesn't matter that AI-coding is taking over: if AI is being used in a brain-dead manner, then you should expect brain-dead results. You didn't review the code as the principle responsible party? The fault for the AI-induced failure nevertheless rests at your feet.

If, however, you apply decades of software development best-practices, you very definitely get living, vibrant, powerful results - the same as if you had a fleet of junior devs, assuming you treated them properly in the first place as well ..

0 comments

anal_reactor8h ago

> You cannot just ignore natural laws and assume, because you 'know better', your software will 'be better'. And whether we like it or not, all software follows a philosophically natural law, which has evolved over decades of human attention. Ignoring these natural laws (...) is only gonna get you butt-hurt, kiddo.

If only you could just read these words back to yourself. Designing perfect software is NOT the case 90% of the time. 90% of the time the entire purpose of software is to facilitate business so if business says "prioritize speed over quality" then you shut up and do exactly that.

Imagine owning a bakery and telling the employee "we need more donuts faster, stop spending ages decorating every single donut like god damn Picasso, just do whatever and move onto the next one, customers are waiting" but instead the guy goes on a rant that nooooooooo only the perfect donuts should be sold, if the glazing isn't perfectly distributed it ruins the flavor profile, which is a real disgrace to the art of making donuts... bro this fast food, stfu and make the donuts faster, we have ten H-1B Donut Artists waiting if you don't like your role.

aa-jvOP7h ago

Its an utter fallacy to state that you have to stop doing quality processes if you want to deliver software, rapidly.

Abandoning quality review steps only seems to be 'more efficient' if you're utterly crap at doing quality processes in the first place - but, the more you do them, the better you get at it, faster - so really you're just saying "people who are crap at doing quality-control processes on their software don't want to have to get better at doing quality-control processes, because it just slows them down" .. effectively ignoring the time wasted in bug triage and other user-unfriendly experiences that result from this lack of quality process, down the line...

So I don't buy your argument. I think you might just be crap at software quality processes and don't want to be reminded of it. Maybe you make donuts - some of us actually serve healthy software to our users.

And many of us do it just as quickly as the guy throwing pieces away that he doesn't know how to use, effectively. Albeit, with much higher quality results, naturally.

anal_reactor6h ago

> effectively ignoring the time wasted in bug triage and other user-unfriendly experiences that result from this lack of quality process, down the line...

The problem is you circled back to valuing user experience itself, while MONEY(UX) looks like a sigmoid, not linear. As long as the UX isn't so horribly broken that most of your customers walk away, it's stupid to spend resources improving UX because you'll get marginal gains at best.

The largest airline in EU is Ryanair. You book it because it's the cheapest. The flight is delayed so you're late for the train, the seats are uncomfortable, customer support doesn't exist, you get constantly bombarded with ads, your day is ruined. You hate it but what are you doing to do next time you fly? Book Ryanair because it's the cheapest. You know it, they know it, your mom knows it.

1 more reply

j / k navigate · click thread line to collapse