Breakthrough Thinking · Part 1

What a 1990s book can teach us about programming in the age of AI.

We can build solutions faster than ever. Are we getting better at choosing the problems worth solving?

What can a book written in the 1990s teach us about software development today? Quite a lot, I suspect.

AI can generate code, debug features, and sketch entire applications in moments. But the speed of a solution doesn't guarantee that we started with the right question.

In Breakthrough Thinking, Gerald Nadler and Shozo Hibino explored an approach to problem-solving that begins with purpose. Their ideas predate today's AI coding assistants, but the central challenge feels surprisingly current.

Before “How?”, ask “Why?”

In software development, we often begin with a feature request: “How do I build this dashboard?” or “How do I automate this process?” Those are useful questions—but they can hide a more important one.

What purpose are we actually trying to accomplish?

Maybe the dashboard isn't needed. Maybe the real problem is that someone can't find an answer quickly. Maybe automation isn't the best first step; maybe the process itself should change.

As we build at Pennington Labs, this is the connection I want to explore: how can older problem-solving principles help us make better decisions with newer tools?

The seven principles—and what they might mean for coding

Nadler and Hibino describe seven principles of Breakthrough Thinking. Here's a first look at how I want to test them in modern software projects:

1. Uniqueness: Treat each problem in its own context. Before copying a template or asking AI for a standard solution, learn what makes this user's situation different.
2. Purposes: Start with the outcome, not the feature. Ask what the software must accomplish before deciding what to build.
3. Solution-After-Next: Look beyond the immediate fix. Will today's architecture still make sense when the next need arrives?
4. Systems: Consider the whole workflow. A polished screen won't help if the data, handoffs, and real-world process don't work together.
5. Limited Information Collection: Gather the information needed to make the next good decision—not every possible detail before taking action.
6. People Design: Include the people who will actually use and maintain the software. Their experience matters more than a technically impressive demo.
7. Betterment Timeline: Think in stages of improvement. Ship something useful, learn from real use, and keep making it better.

Those are starting points, not finished answers. In future posts, I'll take each principle into an actual coding decision—from feature requests and AI prompts to testing and release planning.

The first experiment

Before asking an AI assistant to generate a feature, try writing one sentence describing the result you want for the person using it. Then ask whether the proposed feature is the simplest way to achieve that result.

That's a small shift, but it changes the conversation—from producing code to solving a problem.

The next articles will explore these ideas further, one principle and one programming example at a time.

Pennington Labs · Software built for the real world.