Developing Software is a knowledge-building process

Software development is fundamentally about learning: we learn through building, delivering, and gaining user feedback, which allows us to refine the system iteratively.

Hello, developers! 🚀

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!

As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇

Now, let's dive into today's micro-topic!

In short

🧠 Software development is fundamentally about learning: we learn through building, delivering, and gaining user feedback, which allows us to refine the system iteratively.

🚧 Traditional methods like Big Design Upfront fail because they assume all knowledge can be gained before building. In contrast, iterative approaches, such as "build to learn," acknowledge that the best solutions emerge over time, as we experiment and adapt based on customer input.

🔬 Each software release should be treated like an experiment. By testing small assumptions with minimal investment, teams can quickly adapt and discard what doesn't work, continuously refining the system.

Accept the unknowns

There are two major schools of software development: "'Learn to build" and "Build to learn," I take the build-to-learn approach exclusively. Up-front discovery is almost always a waste of time. […] (Allen Holub on LinkedIn)

Building software is all about learning. At the start of every project, we know very little. We may understand the problem, but we definitely don’t know the best solution, or what the user truly needs. We learn by doing, by delivering, and by getting feedback from our users.

Software development is a learning process. That’s why preventive approaches like Big Design Upfront often fail. They assume we know everything from the beginning, or we can somehow build that knowledge upfront; the reality is that the best solutions emerge only after we’ve started building and interacting with the customer.

Among all the way people have described this iterative approach, I love Allen Holub’s “build to learn” definition I quoted at the beginning of this post, because it implies the movement happening in the real world over time: we need to build something in order to start learning from customer what actually works for them, and iteratively continuing to do that in order to build more knowledge to keep improving the system.

Treat Software as an Experiment

Another great idea you can often read from Allen is that every piece of software we deliver should be treated as an experiment, which means:

• Justify that piece of code with an assumption

• Spend as little as possible to test the assumption

• Learn from what works to create the next assumption

• Drop what doesn’t work

[…] Control costs by building small and releasing often, not by delaying until you can "get it right”.

This is entirely aligned with the “baby steps” idea from XP and TDD: once you become fluent in doing one baby step at a time, you can do so many baby steps in sequence that it seems like you are running faster then ever.

The need for baby steps is given by software development nature of a trip in the unknowns: we don’t actually know what is the best solution to build, so we build it one small step at a time, and adapt the direction based on feedback so that more customers possible are happy and willing to pay for it.

Until next time, happy coding! 🤓👩‍💻👨‍💻