1 reaction

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. Millions spent on market research and product development. Entire departments dedicated to improvement. Then along comes AI, and most of those same companies react with "Yay! We can now fire all those expensive engineers." I call bullshit.

What they're doing is keeping the pace of work constant by reducing the workforce in proportion to perceived (possibly not real, but still perceived) productivity increases. Those companies never intended to even start anything on those expensive lists. Those features were never going to be built. Those bugs were never going to be fixed. Creating and managing those lists was all about fiefdoms and power—busy work that keeps the managers' paychecks coming. The lists are entirely political and entirely fictional. If that weren't the case, those companies would be looking at AI and saying, "Finally. We can get some of this stuff done!" They aren't.

So, what the introduction of AI has done is make the bullshit crystal clear. If you fire people, you don't care about improvement; you don't care about getting those "essential" things done; you don't care about market expansion or new customers; you don't "put your employees first." What you do care about is maximizing profit by providing the least value with the least effort.

I don't necessarily see anything wrong with that—it's a viable business strategy if your plan is to bail as soon as you go public—but let's at least be honest about it. The pretense benefits nobody. In fact, we could save a ton of money by dropping the pretense entirely and not doing the busywork.

We can argue whether mediocrity is a good business strategy. It certainly leaves you vulnerable to competition. But the AI has made the company's actual strategic goals crystal clear: be as mediocre as possible and still make a profit. So, there.

P.S. Elsewhere, I've been told that a one-on-one process won't "scale." That's been proven false by existing 500-person large-university classes in which a competent graduate-level teaching assistant runs the discussion groups. Tell the TAs to spend more time discussing instead of grading papers, and you're there. Upper-division and grad classes are small enough that a professor can teach directly. If all the classes you'll ever take have 500 people in them and you never interact with a human being, you're attending a for-profit degree mill, not a university. Unless the resulting piece of paper will actually get you that high-paying job (unlikely), go elsewhere. You're not learning anything in that environment.

The single practice that is mandated is: “the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” We are constantly improving how we work (uncovering), which, to me, suggests that we add, remove, and change things, and we make those changes based on observation and assessment.

This attitude is particularly important when a radical new tool, such as an LLM, emerges. We improve “by doing it.” We use the new thing, then decide based on our experience. We don’t just sit back and say it doesn’t work because it’s not what we’re doing now, or because some moron has hyped it too much. Agility is scary. It requires constant personal experimentation with new ways of working. Some of those things work, some don’t, but you don’t know until you try.

The next important word is “ways,” plural. I’ve never seen any good come from everyone marching in lockstep to a specific process or framework. At best, that uniformity adds friction. At worst, it adds dysfunction. Every team, every story, every situation, is unique and requires unique ways of working. Create a set of values and principles, and as long as people adhere to those, you’re golden. The people who do the work are in the best position to figure out how to do the work. Of course, control-obsessed people high up in an organization hate that because they can’t control it. They call it “chaos.” Replacing control for trust is an essential element of becoming “Agile,” however.

Finally, the end of that initial sentence is “…and helping others do it.” We improve as a community through collaboration and communication. That can be fraught. E.g., the #NoEstimates tag began when Woody Zuill posted that his team had just finished a successful project without estimates and wanted to share their experience. Instead of “that’s interesting, tell me more,” the reactions were often hateful attacks that came down to “It’s not possible to work without estimates, so you’re an incompetent, irresponsible liar.” But it is possible. It did work. That was the whole point. Working is the starting point of the discussion. Your comments don’t hold much weight unless you’ve tried it. If you don’t know how to try it, talk to the people who have. Conversation and experimentation fill in the details. That’s how you learn and improve. That’s Agile.

Deming once said, “You can measure only 3% of what matters,” and this is one of those cases. All the “productivity” metrics I see measure output. You are not productive if you produce vast amounts of garbage quickly (PRs/unit time come to mind). Even “_value_ delivered over time” isn’t measurable, because you can’t measure value. Productivity matters. You can’t measure it, however.

Sometimes, a group of metrics taken together can help. The DORA metrics (deployment frequency, lead time, change-failure rate, and mean time to restore) taken together come to mind. None of these, in isolation, does anything useful. A team with a high deployment rate is productive only if it also has a low failure rate, etc. It’s all or nothing.

But even taken together, DORA metrics are not sufficient because they’re still output measures. Take lead time: the time from when a problem is identified to when the solution generates revenue. (Idea to the customer’s hands.) Some problems are just harder than others, so they take longer to solve. That extra time doesn’t mean you’re less productive, however. A simple lead-time comparison tells you nothing useful.

People talk about how AI assistance makes them more productive, but that’s particularly fraught because the “out of the box” code always needs to be inspected and refactored. People who check in unreviewed code are actually anti-productive because someone down the line will have to deal with the problems in that code. AI-generated code is also overcomplex, and if somebody doesn’t deal with that complexity, it will kill you down the line. I’m not saying that using AI is not a good thing. It does make people more productive. Just not in an easily measured way, and only if the programmers approach the generated code with scepticism.

Deming also said, “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.” You can’t measure productivity, but you _can_ manage it. The best indicator I can think of is how long it takes to make a necessary change and how solid that change is (solid code stands up over time). “Solid” applies to everything from code quality to whether your solution to a customer problem is a good one.

When the change time is low, productivity is high. If the code isn’t solid, the constant fiddling with it lowers my productivity. We’ve all experienced code that’s hellish to work on, where a change that should take a few hours takes weeks. When I work in code like that, I’m not productive (and very unhappy). This is a relative measure. Some things—some changes—are just inherently difficult, so take longer than others.

So, even if I can’t measure my productivity, I can manage it by looking for things that slow down change and eliminating those things. There are many specific things that slow me down. Wrestling with bugs. Dealing with unnecessary complexity. Inappropriate or bad architecture. Bad overall code structure. Unhelpful names. Low quality in general. Code that doesn’t make what it does obvious when reading it. The list goes on. By dealing with those things, we become more productive. If you want to measure something, measure how many of those issues you address.

A Buddhist monk (yes, seriously) once told me that suffering is the distance between the way things are and the way we think they should be. Productivity works the same way. The smaller the gap, the more productive we are. Productivity is a relative delta, not a hard number. Narrowing that gap reduces our suffering 😄.

Don’t get me wrong, the world does have a use for a degree that focuses on the mathematics that underlies computing, algorithm design and analysis, NP completeness, and the other things that go into a Computer Science degree, but that stuff has little or nothing to do with the production of software. Put another way, computer science is to software development what materials science is to architecture. The connection is tenuous, and a degree in the first does not prepare you for a job in the second.

In the current job climate, the CS curriculum is a tragedy. Learning software engineering on the job to make up for educational deficiencies is a luxury that requires a strong economy and companies with money to burn. We don't have that. Sure, a university is not a trade school, but I'm talking about basic essential knowledge and skills, not the details of using specific technologies.

If AI requires the thinking of a "senior" and the schools don't teach the things a "senior" knows, even though they could, then they're failing as educational institutions. There's no reason for that. Similarly, there's no reason for schools to churn out people with no experience or knowledge of how to create real software. They can teach that, too. They can require significant projects as a graduation requirement. They can support and encourage internships (see: Drexel, Cal Poly, VCU). It's a truism that the only constant in software engineering is change, but that doesn't make it any less accurate. A hidebound university system (with a few notable exceptions) is failing us. The fact that many of the CS-degree requirements are the same now as they were when I was in school, back when dinosaurs roamed the earth, says nothing good.

PS. To address a misreading of the above that's popped up elsewhere: I am not saying that universities should teach a tech stack. I am saying that they should teach software engineering: how to work in teams, how to write production-quality programs that people can use, how to work incrementally, software architecture, basic processes like CI/CD and testing, and nowadays, AI-assisted software engineering. None of this has to do with specific tech.

We need to rethink the role of a Computer Science (a narrow specialty) degree in hiring and instead focus on Software Engineering degrees. Universities that don't offer a true Software Engineering degree are not really doing their jobs, in my opinion. They are not teaching an essential discipline.