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

If the same issue comes up in Tech Support more than a handful of times, you have a design, not a support, issue. Often, devs don't fix the core problem, so the support people come up with a book of workarounds. That book is a design document. It's your job as a dev to make that book unnecessary.

ISTM that above-average communication skills are an essential part of the programmer's job—always have been. The days of locking a developer in a room and throwing meat under the door once a day are over. To me, programming has always been a social skill, even more so if an AI is involved. 1/5

In general, if you need to change a test because you changed the code, you didn't have a test at all. The whole _point_ of a test is that, when I make a change, I want to run the test to see if I've broken anything. A good test works both before and after the change. 1/4

"Unambiguous English" is an oxymoron—something that the no-code vibe coders don't seem to understand. Adding more English makes a specification more complicated, but not less ambiguous. 1/2

I really don't get "spec-based development," which is nothing but a fancy way to describe a phase-gated "waterfall." An upfront specification is never correct, at least if our goal is to develop software people actually want to use. The more detailed and larger the spec, the less correct it is. 1/5

I'll admit that I get annoyed by irresponsible use of AI. I characterise that by systems that use AI when other perfectly good non-AI solutions abound. It's an inexcusable waste of resources. High on my list is @Amazon's Alexa web application (alexa.amazon.com). 1/6

I'm an AI-is-a-useful-tool person, but judging by @Amazon, which has gone full AI and is pressuring its engineers to use more, it might be best for some companies to avoid AI entirely. 1/8

So what was agile actually about? Build small. Ship it. Get feedback. Adapt. That loop is more relevant now than ever. The frameworks around it? You can throw those away. @allenholub.bsky.social stellarwork.start.page

All plans implicitly pose the question: "Will this approach work?" The only way to find out is to start executing the plan. When (not if) it doesn't work, because you never have the information you need up front to assure that it will work, the plan has to change. 1/2

Plans are not roadmaps; they are sea charts. Chart your current position, your destination, and the known hazards; the route changes with the wind. Plans are experiments that need to be validated as they unfold. Plans are questions, not answers.

We don't spend enough time thinking about strategic planning around the actual cost of using an LLM. The AI companies are effectively borrowing $1,000 for every $1 of revenue. 1/13

I often hear: "The users will _love_ this." They don't.

I've noticed a common scenario, which I call Complaint-Driven Development (CDD). A company introduces a new "feature" that people hate. When enough people scream about it, the vendor reluctantly adds an option to turn it off. Off is never the default, which people also hate. 1/4

If your entire job is: receive spec, write code, hand it off, repeat... you should be worried. As @allenholub.bsky.social put it: coding was maybe 15% of the job. The rest was thinking, designing, testing, talking to people. AI made it impossible to ignore. open.spotify.com/episode/41gZ...

Agile is dead. At least the word is. @allenholub.bsky.social won't use it anymore. Neither will @kentbeck.com with XP. Not because the ideas failed. Because the industry turned them into a certification machine. -> stellarwork.start.page

The notion of delaying decisions to "the last responsible moment" is important. For some decisions, that moment is pretty early. For example, we need to develop strategic plans and do customer and market research early in the product development process.

I keep hearing that AI has made Agile irrelevant. Okay. I'll throw in the towel. Let's dump Agile altogether. So, instead, here is by far the best AI-focused way of working that I know: First, - The way we treat people and work with them is more important than processes and tools

All data centers combined account for about 0.5% of global carbon emissions. Of that, ~10% is AI-related, so AI is responsible for 0.05% of global carbon emissions. Cars and other transportation account for ~25% of total emissions. Just 'sayin.

The very existence of options and settings is usually a sign of indecisiveness and poor product research. They tell me the programmer hasn't done their homework (e.g., talking to customers), so they have no idea how something should work. 1/7

I've just read about "tokenmaxing," which uses the number of LLM tokens you blow through in a month as a sort of sick productivity metric. This is insane. 1/8

The thing that makes a "mature" team "mature" is what the people who comprise the team know. It has nothing to do with how long they've worked. There are many people who have done the same wrong thing year after year for decades. You want a mature team? Educate them. 1/2

There isn't an LLM on the planet that understands architecture. No LLM can create an effective architecture. Architecture is contextual, dependent on things like the domain. Architects use judgment and creativity. No "AI" can do either. There is no "good" cookie-cutter architecture. 1/6

Pull Requests (PRs) solve one problem only: you have broken up the work into small chunks that are completed by untrusted (and often unknown) individuals working in isolation without support or help, who produce potentially destructive changes, … 1/5

ICE detention deaths are now occurring at a rate of roughly one every four days. Three weeks ago that rate was one every six days. The pace is accelerating, and Congress has not launched a single investigation.

The attached post is interesting in that it argues AI is dangerous, contrasting it with a word processor, which the author claims is not. Putting aside the inflammatory rhetoric, let's focus on that "dangerous" notion. 1/12

I mentioned TDD in an earlier post, and it became clear from the responses that there's some confusion about what TDD is. TDD stands for test-driven _development_ (or design). The "test-driven" is an adjective modifying the word "development" (or "design"). 1/10

In all the foofaraw surrounding AI, many people seem to have forgotten that product development is not all about coding, and that coding is maybe 10% of the actual work. 1/7