I'm a big fan of this explanation/rant from Andrew Murphy.

Taken as a whole, there are many bottlenecks in a corporate software development process. The "load-bearing" calendar is a great example!

Speeding up code creation just increases pressure on the bottleneck, which decreases throughput.

https://andrewmurphy.io/blog/if-you-thought-the-speed-of-writing-code-was-your-problem-you-have-bigger-problems

If you thought the speed of writing code was your problem - you have bigger problems | Debugging Leadership

AI coding tools are optimising the wrong thing and nobody wants to hear it. Writing code was already fast. The bottleneck is everything else: unclear requirements, review queues, terrified deploy cultures, and an org chart that needs six meetings to decide what colour the button should be.

Debugging Leadership

So why are we still trying to optimize code creation?

For decades, people with power - executives and product people - have been shifting the blame for strategy failures and poor market insight onto development "productivity."

This AI moment should be incredibly clarifying. Like, it should be the reductio ad absurdum of a productivity-centric approach.

The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know.

There is no flourishing of value delivery, new product categories, more needs being satisfied better. It’s the opposite.

All we are seeing is decreases in quality, because 👏 code 👏 creation 👏 is not 👏 the problem.

@elizayer

The good news is :

Open source maintainers see an increase in the quality of AI security tools, it will soon be in the hands of the bad actors.

Then it will be mandatory to do good software and ( i will make the leap of faith that ) you have to understand the business needs to create a simple software that handle the issues.

@Aedius

30 years ago I taught Structured Systems Analysis and Design classes and consulted on client projects using the CASE (computer aided software engineering AKA data and process modeling software) tool I resold.

The core purpose was to ensure a joint correct understanding with the business of the requirements new or purchased software (components) needed to meet and designing clean and supportable software to implement those requirements.

You won't be shocked to learn ...
@elizayer

@Aedius

that upper management never caught on to the superior effectiveness and efficiency of building the correct solution the first time despite not a line of code getting written for many months.

I did a BPR project ( I didn't know it was a BPR project as the book hadn't been written yet) to migrate a smallish non-profit from a cranky and poorly designed mainframe system to client server.
We spent 9 months modeling the requirements and ...

@elizayer

@Aedius

system design.
It took us 2 months and change to code 90% of the requirements. Rolled it out and completely reorganized their workflow without a serious issue.
They ran on that Paradox for DOS system for many years and grew their business throughout without the need to expand their core staff while supplying greatly enhanced service to their customers.

They're still out there - https://www.cgfns.org/

@elizayer

Serving global nurses and allied healthcare workers with credentials evaluation and career mobility since 1977.

CGFNS International, Inc. has been the world's largest credentials evaluation organization for the nursing & allied health professions since 1977

CGFNS International, Inc.

@joeinwynnewood @Aedius Amazing! I love a success story like that.

Of course... not all engineering teams are successful at the up-front work. Often out of a combination of weak engineering skills and the wrong environment...

I've come across very few senior managers who have the skill to create an environment where this is possible! Would love to see a recognition of this in leadership circles :sigh: