Kevlin Henney - The Case for Technical Excellence

The Case for Technical Excellence
One of the (most overlooked) principles of the Manifesto for Agile Software Development is that "Continuous attention to technical excellence and good design enhances agility". All too often, work that focuses on addressing technical issues is deprioritised in the name of focusing on business value.
Is there a case for technical excellence - in code, in architecture, in people - beyond its appearance on a might-as-well-be-hidden page on a manifesto that's over two decades old? Is technical excellence only the concern of technical roles? Is a good architecture in conflict with business value or a vehicle for it?
This session looks to go beyond buzzwords to build a case for technical excellence that appeals to all roles in a development organisation, noting that "The best architectures, requirements, and designs emerge from self-organizing teams".
Agile Meets Architecture 2023
www.agile-meets-architecture.com
#amaberlin

[@alexanderpodkopaev6691]

Many thanks for pointing to 'business value' ! I was surprised to find out that a lot of 1st line managers and team leads in the outsource company does not have clear sense of this tricky balance of value to the customer vs value to the employer.

[@soulGrafitti]

Always enjoy working Lakoff into a tech discussion.

[@dash9655]

No disagreement, but what to do when sales and management keep promising feature after feature, to keep the customer buying, and you spend more and more time adding quick and dirty features and fighting fires instead of repaying the technical debt? This can't end well at all, that is obvious, but how do you get out of this cycle?

[@vinzzz666]

I'm not so sure about the French proverb thing. It is "Je suis a Paris.", but is also: "Je suis en France". The French proverbe "en", is not really a contraction of "à" and "là" but is specially used for countries. In both cases they mean "at".

[@dash9655]

I'm in town, at the bookshop.

[@defipunk]

Curious to see your opinion on large (100s or 1000s) orgs working in one code base, where VPs may continuously kingdom-build and reorg. I believe this is the "self-organized" being violated. There is also something about the number of people sharing ownership or having in the past had ownership that leads to degradation of code quality

[@gruttewibe76]

Yes, when teams are formed, changed and disbanded at will by management then there is little space for self-organizing teams. It also has the effect that code ownership gets changed, and people will start getting detached from it, not feeling responsible, not feeling pride to keep it clean.

[@edgeeffect]

Kevlin: "There's a word for this..." Me: "BOLLOX!" Kevlin: "The colloquial term is 'bollocks'" Me: (small choking fit).

[@safulkin]

"quick and easy" vs "quick and dirty". I've expect some conclusions