Remix.run Logo
hogehoge51 3 hours ago

Unfortunately I think Cognitive Debt is the cry of the software craftsperson who thought they were an Engineer. Upon working with the agent subcontractor, the agent factory, the agent part vendor, they approached it as a craft; they found themselves wanting to walk through the offices of the subcontractor reviewing screens, inspect pieces at the factory, and get the internal design for the parts they ordered. It's natural to get overwhelmed: this is why Engineers have contracts, specifications, design drawings, datasheets, and characterization data, handed over at clearly defined boundaries of abstraction, accepting the other side may be a black box.

Of course, we have had compilers and tooling, but those are the pencil and drafting board of the draftsperson. An ecosystem of packages, dependencies and APIs has evolved, but those are often just spells the software magician invokes after reading the spellbook^H^H^H^H^H^H^H^H^H stackoverflow^H^H^H^H^H^H^H^H^H^H^H^H^H API documentation.

We are going to need to build a new set of boundaries and abstractions with new handover protocols to manage this mess.

praptak 16 minutes ago | parent | next [-]

There is no party capable to take responsibility on the other side of the handover protocol.

platzhirsch 2 hours ago | parent | prev [-]

Because waterfall software engineering has been so successful, right? ;-)

onion2k 2 hours ago | parent | next [-]

Lots of very successful software was built using a waterfall approach. It's a methodology that works well if you know precisely what the end result needs to be. That doesn't make it appropriate for everything - if you don't know what the customer needs, or if you want to get an MVP out, then Agile works better, but you shouldn't dismiss an approach because it doesn't work everywhere.

Plus, 'agile' in quite a lot companies is really waterfall that's been broken into sprints without the planning of proper waterfall or the discovery and learning of real Agile. The software still gets built though. Maybe software is actually quite easy to plan.

mikestaas an hour ago | parent [-]

Agilefall, the worst of both worlds.

saulpw 2 hours ago | parent | prev [-]

Because agile has been so successful, right? ;)

marcosdumay 2 hours ago | parent | next [-]

In fact, agile has been extremely successful.

It's the people that claim to "do agile" that invariably don't do it. But software development used to fail most of the time, and it doesn't do that anymore.

scorpioxy 2 hours ago | parent | next [-]

What makes you say that it has been extremely successful? And when you say doesn't fail anymore, do you mean it doesn't go over budget and/or changes scope?

Turskarama an hour ago | parent [-]

Agile cannot go over budget or scope because those are failures of planning. Agile is the methodology that was developed specifically to counteract those problems with planning. Projects that use Agile can go over budget and scope but they never do that because they are using Agile, rather they use Agile because they might do that.

sevenzero 36 minutes ago | parent [-]

It always felt like Agile is the lazy attempt of people unwilling to learn what it takes to build software, to make it more predictable. Unfortunately project planning methods that work for buildings are not really great for software. It's just corpo stuff project managers do to feel meaningful.

s-lambert 38 minutes ago | parent | prev | next [-]

It used to fail once after a long time, now software fails a lot every 2 weeks.

philipswood 27 minutes ago | parent | prev [-]

Waterfall was also extremely successful.

People who failed just did it wrong. /s

platzhirsch 2 hours ago | parent | prev [-]

Agile fails when folks don't adjust and tailor the process to the specific needs of their team or organization but instead try to cargo cult it.

vrighter 2 hours ago | parent [-]

so it's called agile when it works, but not when it doesn't, got it!

an hour ago | parent | next [-]
[deleted]
habinero 2 hours ago | parent | prev | next [-]

You gotta understand how to use a tool for it to be effective, yes.

scorpioxy an hour ago | parent [-]

And if a tool is that difficult to use, how can you tell if the problem is in the tool or the user? There's a large industry built around doing training and certifications in agile methodologies now. If a tool is that difficult to get right, maybe it's just not a good tool to begin with.

To be fair, the manifesto and methodology is quite good in theory. But I just have never heard of(or experienced) it working properly and the response is always that it wasn't implemented correctly.

2 hours ago | parent | prev [-]
[deleted]