Another ridiculous poll. What actually slows releases? 1) Building things nobody wants. 2) Unnecessary complexity. 3) Lack of effective communication. 4) A culture of centralized control. 5) Bad process. 6) Dependencies. 7) Not trusting the people who do the work. 8) Large batches. 1/2

I recently came across this misguided poll 👇. The answer is none of the above. The biggest QA challenge is creating a culture of quality that pervades the organization. 1/2

"On time and in budget" is a disaster when that thinking forces software to be released before it's ready. My current health plan's (Kaiser) software is a case in point. They released the new version on time! — riddled with bugs. 1/3

Regarding the speed of an AI and the volume of code it can create: None of that matters.

Planning is overrated. (And please don't trot out that Eisenhauer chestnut—we are not the military.) As Woody Zuill said, "We learn what to do next by doing the current thing." When we release that current thing and get feedback (you are releasing in small increments and getting feedback, 1/6

In a culture of "meritocracy," hiring someone more competent than yourself is job suicide. You are hiring your replacement. Hiring becomes a race to the bottom because nobody will put their own job on the line. This is no way to run a company. 1/2

Many people have heard of Parkinson's Law (work expands to fill all available time), but haven't thought about how that actually works. Here's one of Parkenson's examples: Someone in the organization is overworked. 1/5

Now here's a thought: the people you hired because of their competence are actually competent. They know how to do their job. Perhaps you should just get out of the way and let them do that. Control-focused management is just mansplaining on steroids. Just stop.

Earlybird tickets for our YOW! Masterclass with @allenholub.bsky.social are almost gone. Use promo code 'earlybirdclass' to save $180 on your ticket! MEL 2 Dec yowcon.com/melbourne-20... BNE 9 Dec yowcon.com/brisbane-202...

No software development organization needs a standardized process. 40 years ago, Watts Humphrey, funded by the US Department of Defense, came up with something called the Capability Maturity Model (CMM)—one of many grasping-at-straw attempts to get DoD spending and quality under control. 1/11

<rant> Story points are like cockroaches. Just when you think that you've stamped them out another army of them crawls out from under the sink. Points have no value. None. Nada. They are an utter waste of time. Fibbonocci sequences just heap more garbage onto the pile. 1/5

One of the things that non-programming users of AI don't seem to consider when they spout off about "productivity" is the phone-spam effect. Phone spam has destroyed the telephone as a viable communication device. Who answers their phone anymore? 1/5

When programmers talk about how productive they are with AI, they tend to forget that they are working for businesses, where the only metric that matters is profit, and where the behavior of the overall system of work is the important thing, not the behavior of one small part of it. 1/5

I am so sick to death of people talking about the "competitive advantage" that AI gives you. That's complete and utter hogwash. AI has zero impact on competitive advantage. Competitive advantage comes from building a high-quality product that people want to buy. 1/4

"The design is the work; the code is an artifact." I agree with that, but my take might not be what you're thinking. 1/10

In my normal programming work, I use AI tools in a very focused way that I've been told is "wrong," even though I'm more productive, but there we are. I'm not spewing out 20x my previous output, so maybe that's it. I'm an engineer, so when I work with an LLM, I do engineering. 1/13

My measure of productivity is the time it takes to get the solution to a user's problem (their story) into their hands. I couldn't care less about vanity metrics like output volume or token counts. What matters is delivering value sooner. 1/2

Productivity doesn't matter if you're working on the wrong thing.

The attached post 👇 is absolutely true for those companies that approached AI in a mindless way. The fact is that pretty much everybody is using AI. The "you'll be left behind if you don't adopt AI" thing is stale. Everybody's adopted AI. 1/10

I talked about MVPs yesterday, but there are two related concepts, often confused with MVPs, that are also worth mentioning: prototypes and PoCs 1/10

Judging by posts I've seen, it's time to talk about MVPs. There's a lot of misunderstanding of the notion. People take the acronym too literally. There are two definitions of MVP. 1/12

When it comes to learning AI-augmented software engineering online, Sturgeon's Law (90% of everything is crap) applies, though I think the percentage is closer to 99%. The providers I usually trust (e.g., O'Reilly) are just as unreliable as everything else. 1/5

OH: "I am learning and writing code, but my experience is probably very different from a real programmer." If you're creating code, you ARE a real programmer! All of us are learning. All the time. It's the people who aren't learning who have problems.

I just watched a @udacity video about building AI Agents. It started with the presenter admitting they knew nothing about product development, couldn't tell us what the acronym PRD stood for, and then presented a really awful PRD as an essential first step in the work. 1/12

Tim Ottinger posted this drawing over on LinkedIn 👇 [https://t.ly/bll9E]. He's absolutely correct about this. Here's an example: I once built what amounted to a small blog system that had a comments feature. My initial idea was a standard comments dashboard. 1/11

All too often, the word "leader" is used to describe a mere manager. That's not a leader in any real sense. You cannot be anointed as a "leader" by upper management. Leadership cannot be imposed. 1/5

Programming has nothing much to do with math. It is primarily about communication. It's about us communicating with customers and us communicating with the machine. Programming is a language skill, not a mathematical one. 1/7

Comparing software development to bridge or building construction is a completely bogus straw man. 1/5

At the top of the "are doomed to repeat it" category is the notion of "spec-driven development" (SDD). 1/7

Spotify embodies a couple of fail-to-grasp-the-concept issues that are worth discussing. First, some background: I've never liked Spotify's conceptual architecture, particularly the missing notion of a music library. Likes, Artists, Albums, &c., are all separate buckets. 1/11

People seem to have forgotten that the point of creating products in small iterations is to get the continuous feedback necessary to produce a great product. It has nothing to do with coding mechanics. 1/9

One of the dysfunctions that AI amplifies is the software industry's focus on output. The move to AI is all about increasing output. Robot monkeys type faster and produce more output than people. The problem, of course, is that it's never been output that's the problem. 1/10

Software development is a dance. Developers and managers could learn a lot from partner dancing (actual dancing, not the choreographed Dancing with the Stars stuff). 1/11

One of the things that AI in software dev has gifted us is a first-class bullshit filter. Consider your backlog or strategic plan. Most companies have long lists of things they want to do. They spend a fortune on creating and managing those lists. 1/8

We’re launching our 1st #YOW26 Masterclass with @allenholub.bsky.social: Practical Software Architecture for AI (And Everything Else) 🎟️ Save $180 with promo code 'earlybirdclass' ⏳ Limited tickets until 30 Jun 📍 MEL 2 Dec yowcon.com/melbourne-20... 📍 BNE 9 Dec yowcon.com/brisbane-202...

No organization ever failed by not being Agile enough. Many organizations fail from a lack of agility, however. These are very different things.

This morning, I was reading an article about U.C. Berkeley students effectively cheating with AI [https://t.ly/yPj8F]. People are, of course, wailing and gnashing their teeth over the state of higher education, saying that AI is dumbing down our entire society. 1/9

I've been working on a new Software Architecture class description (more on that in a day or so), and Google Docs just told me that the document was, at least in part, AI-generated. None of it was AI-generated. That presents something of a conundrum. 1/8

To me, tests are part of your system and its architecture, not a separate thing that's tacked on as an afterthought. As such, architectural principles that pervade the system must extend to the tests. Testability is an essential architectural characteristic that pervades the system. 1/9

In the continuing saga of @ebay turning to crap, the entire site is down this morning. You'd think they'd want to get a handle on quality, but I guess AI is more important 🙄

What's the difference between a use case and a user story? Bob Martin describes use cases pretty well in his book Clean Architecture: "A use case is a description of the way that an automated system is used. 1/7

Surely ebay has the money to do basic QC. I'm getting so tired of this stuff, and "AI" is making it much worse (though, honestly, this might be plain old amateurish programming). No, you can't trust the generated code. Sorry.

DRY (don't repeat yourself) is actually a bad idea in many situations. For example, in a service (or microservice) architecture where you want independent deployability, two services sharing a library are effectively coupled not only to the library but also to each other. 1/3

The iron triangle (time, cost, scope) has been around for at least 40 years. The basic idea is that only two of the points can be fixed. Fix all three, and you have a death march. It's not like we don't know that. 1/6

This is just perfection

If shipping your software is a big deal, you're not going about developing that software in the best way, I think. I ship daily, or maybe weekly, but shipping is a non-event. It's a side effect of a daily (or more frequent) commit. 1/2

The related notions of "behind schedule" and "scope creep" are fundamentally wrongheaded. It's 50-year-old thinking that many of us have abandoned because it doesn't work. "Behind" implies an accurate estimate of a large, detailed specification. 1/10

When you pose a question to a computer, it should provide you with the answer, not the wherewithal to formulate the answer manually. 1/3

This is a gluton-for-punishment post, but so be it. Search engines are dead. Nowadays, I'm using Claude (or duckꓸai, which takes privacy seriously) rather than Google or equivalent as my go-to for finding information. 1/8

I keep hearing about how critical it is to have domain expertise, and lately, about how you should leverage that expertise to create a spec that you'll implement precisely. The first CTO job I had was coming into a company to try to turn it around. 1/4