In an area dominated by acronyms like DRY, YAGNI, FIRST, SMART, KISS or catchy expressions such as Fake It Till You Make It and Baby Steps, a very important practice which is becoming forgotten is Programming By Intention:
This is the practice of pretending that classes, functions, procedures etc. exist (even though they do not) as you structure and write your code. This helps a developer think about the overall process and larger steps of software rather than the small details.
Although it may sound a little weird, the definition above really points to essence of this practice: pretending a piece of code is there to help you focus on the bigger picture. It forces us to think about what we’re trying to achieve instead of going into all the details first. And this small change in priorities makes a huge difference.
As critical thinkers we are always breaking the problem into smaller pieces and trying to put them together like a puzzle. And sometimes we decide to build these pieces one by one in sequence, and not by importance. By adopting this approach we lose great opportunities to learn early about the solution we’re building. We also lose time refactoring and throwing out code when we realise the pieces could be arranged in a simpler or more understandable way.
And that’s where the beauty of Programming By Intention lies: it effectively helps us to make sure we’re solving the problem first, and writing all the support for the solution later. And that’s why I wish there was a buzzword for it too.
Work
Agile, Craftsmanship, Programming, TDD
How do you tell if a team is agile? If the last years trying to follow the principles of the manifesto taught me something is that in a good software project people want to be accountable.
We’re knowledge workers. What we deliver is a direct result of the perception of the problems we are exposed to. Yet, there are a lot of people trying to escape from the responsibilities our job requires.
Some of these responsibilities include:
- Design decisions (TDD)
- Impact of our changes on the rest of the project (CI)
- Sharing knowledge and the code where it’s represented (PP/Standards)
- Making sure what is delivered has any value (Reviews/Frequent Releases)
In this context there’s no room for peonage. Our job is basically to make decisions all the time and being agile is about making sure we can answer (and answer well!) for our actions.
That’s why I agree with Patrick Kua’s post about this topic. We have to understand the business problems and the possible solutions. We have to help each other to build something. We can’t stop learning. We can’t be limited by our normal role. And most important: we have to care.
Work
Agile, Coaching, Craftsmanship, Teams
In his talk at the Agile2008, Bob Martin proposed an addition to the Agile Manifesto:
Craftsmanship over Crap.
Although most of us can identify with that statement, it’s probably not easy to sell the idea put that way. But now he rephrased it to:
Craftsmanship over Execution.
I confess the first time a thought about software development being a craft was in a Joel Spolsky’s article disagreeing with the use of this term. In the post he suggests creating software is more related to design than craftsmanship, but he reinforces the idea of software not being simple execution.
After working with a lot of different people, it’s easy to distinguish who think about software as being craftsmanship or mere execution. And undoubtedly the best developers and consequently the best software always come from the first category. They care about what they’re producing, are passionate about it and never stop learning. They want to become master craftsmen and know it depends only on their own attitude.
The question is: should the Agile manifesto include that statement? Personally I don’t believe so. The “Individual and Interaction over processes and tools” part already implies that. Focus more in processes and you’ll end up caring more about execution. Value people and the craftsmanship aspect of building software will become natural.
Work
Agile, Craftsmanship, Programming