Understand rather than produce blindly
This is the 1st post from my sincere dev manifesto series.
As a team, we don’t produce features, let alone lines of code. We produce understanding, flowing between our brains and our creature. Our goal is to understand:
- problems to solve, for all stakeholders: users, decision makers, payers, sales, buyers, developers, people keeping the system alive, etc
- constraints, political, technical, historical, human, social, financial, timely, legal…
- options in our reach to lubricate how we share understanding
- options kept in the past
- tensions between goals, values, processes, constraints…
- our creature
- how this understanding is perceived by all stakeholders
If you wipe your code and write it again, you will be several times faster. Because what you do is not actually writing code, but, as Stacey Vetzal puts it, writing documentation for your teammates that the compiler can understand. I would add you’re documenting your understanding of the context.
I prefer a solution that helps me understand the context, rather than a solution that hides every detail, allowing me to avoid understanding. The latter always blow up at your face one day or another. Cyrille Martraire heard from someone that a library is a way to push to the future the moment you need to understand what it does. Eventually, that day comes. And when it comes, I want the lib to help, and have always helped me, understand what was going on.
Don’t fool yourself. It’s not because you have a spec that anybody knows exactly what needs to be done, or the most relevant way to do it. In general, the bigger the spec, the more precise it is, the wronger it is. Every belief needs to be challenged, especially details. Because it’s details that turn your whole design upside down.
What does understanding mean?
- Observe users in their environment. They use different tools or skills than yours.
- Observe users interact with your product. It means pushing features out the door, even if they’re not perfect. Your product changes people’s expectations.
- Get feedback about what you developed once it’s available to users. Features are not done when they’re deployed. They only start to get interesting.
- DDD of course. Listen to the people who know the domain. Write down the words they say. Model your understanding in a way everyone agrees with.
- Exploration, all the way. Find new people to discuss with, experiment with them with mockups or hypotheses. Explore your libraries, your tools, your practices, your design options, your process, your rules…
- Keep your mind open. Be ready to challenge or blow up your models. Ask what this hypothesis being wrong means to your model. Learning is also unlearning, starting over from a fresh point of view.
- Be ready to rollback some “work” (code? doc? conclusion? schemas? agreements?). It isn’t sunk cost, as you gathered some precious understanding along the way (it’s not the destination, it’s the journey).
- Multiply points of views and thus models.
- Surface constraints as well as goals. Fundamental differences between contexts stand in constraints. They make every situation unique.
- Encourage people to fail, i.e. try, i.e. learn.
- Have influential people show a good example, by celebrating failures
Understanding is an ongoing process. We all have to do it every day. Ask questions, listen genuinely, model what you hear, discuss it, be ready to adapt accordingly. Changing requirements, like changing understanding of requirements, are good news.
Understanding is a collective job. Having a lonesome hero understanding it all is sub-optimal, if not useless, if not harmful. Understanding being an ongoing task, this is why I’m talking about understanding flowing between our brains. That’s where useful understanding stands.
Our value as a team is in this collective ongoing understanding, not in our creature or its features. If you want to be mean to your competitors, give them your source code. They’ll just waste time with it.
I commit to taking the time to understand the context, continuously, and making sure that what needs to flow between our brains, and between our brains and our creature, flows.
AAAgile 
3 comments