I’m a huge fan of the (Ries-style) MVP approach. The best way to get a product to your customer sooner is to not waste time building features they don’t want. The MVP helps with that.

Prototypes and PoCs

Two concepts often confused with an MVP are also worth mentioning.

A prototype is a test that answers the question: “Does this design actually work the way we think it does?” You can prototype any aspect of a design, from the UX to the database. Prototypes come in two main flavors.

A low-fidelity prototype is something like a simple whiteboard sketch of a proposed UI. It goes together in seconds and is meant to help with quick decisions.

A high-fidelity prototype is a fully functional model that usually tests the behavior of some part of the program under load or in some real-world usage scenario. It can’t do that if it isn’t full-on production-quality code. Usually, high-fidelity prototypes are massaged over several iterations until they work as expected, and then are inserted into the main body of the code.

Neither of these prototype flavors is an MVP. A prototype tests a design. An MVP determines if a product is worth building. Those are entirely different things, even if they have a superficial similarity.

The other related idea is proof of concept (PoC). You use PoCs very early in the design process to prove that some aspect of the design will work. Typically, they’re used before you get to the prototyping stage and don't look anything at all like the finished product. For example, if you’re worried about database performance, you might kludge together a simple program that does nothing but dump data into the database and pull it back out to make sure the database can keep up with worst-case load. The concept is similar to the notion of a "spike" in Scrum. A PoC is neither an MVC nor a prototype. It’s just testing whether a design decision that’s still under consideration will work out.

So, we have three tools to work with:

MVP tells us that a product is worth building

Prototypes tell us that the design of the product is working

PoCs tell us that core implementation assumptions are correct

All three of these tools are essential, I think, in product development, but they are very different from one another.

That is, do not confuse programming (stories, TDD, coding, debugging, testing, CI/CD, software architecture, UX, etc.) with the problem domain. The domain is distinct from the programming process itself. That is, the programming part is the part we use in every program we write, regardless of the problem we’re solving. Certainly, some problem domains (aviation is often brought up) are mathematical in nature. If you have a fundamentally mathematical problem, you’ll need math to solve it, just as if you have a fundamentally social problem, like a dating site, you’ll need knowlege of dating and human social interaction to solve it. You don’t need dating knowlege to create avionics, and you don’t need math to go on a date (unless you’re dating a mathematician 😄).

So, when a programmer doesn’t have domain knowlege, they use domain experts. Those experts do not, for the most part, know how to program. Sometimes, programmers are domain experts, but not usually, and more to the point, they don’t have to be. A programmer working in a mathematical domain doesn’t need to know any math, provided that they’re working with a domain expert who does (and, conversely, most mathematicians are lousy programmers—I wouldn’t let them touch the code).

Also, computer programs are not mathematical formulae, as some claim. If they were, we could prove program correctness mathematically, and we’d have no bugs. Be nice, but that’s not the current reality. People argue that you can prove correctness in the sense that the code will run, and I’ll buy that. You cannot mathematically prove that the program does anything useful or doesn’t make significant mistakes (i.e., have bugs) at the domain level.

I think this false equivalence dates back to the very early days of computing, when computers were used almost entirely to solve mathematical problems. The Babage engine was a calculator, and Ada Lovelace was a calculator programmer. That was indeed math. Modern computers are far more than simple calculators, and the problems we solve are not simple ballistics and the like. In the present, mathematical problems are only a tiny fraction of the problems we solve.

Of course, computer science—the branch of mathematics concerned with the analysis of computer programs and algorithms—uses math (though the 1.5 years of calculus and differential equations that were required prerequisites for every CS class I took were used in exactly zero of those classes, and I’ve never used either in my work). However, I’m talking about the creation of computer programs, not the analysis of them—programming, not computer science.

So, returning to my original claim, if you want to be a good programmer, forget the math. Instead, focus on developing communication and writing skills. That’s what we’re really doing. When you need knowlege of a domain (math or dating) to write the program, consult a domain expert.

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.