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
Three simple steps to measure velocity in a software project:
- Estimate your requirements using a size metric.
- Agree on the concept of done.
- Define a timebox size.
Then we just need the formula:
Velocity = Points done / Timebox
Work
Agile, Metrics
Just to clarify:
- Integration test: modules of the system are tested together, as a group.
- Integration build: modifications made by developers are consolidated through a full build.
Although the integration build may include running integration tests, they’re are clearly two separate problems.
Work
Agile, CI, Testing
Sometimes in a project:
- People are treated as mere “resources”, being part of the project only to work on predefined activities and nothing else.
- The managers want to be sure that everyone is doing exactly what they think it’s the best, and forget that people can have good ideas.
- People prefer to work on tasks defined by someone else because they don’t want to be responsible for their work.
Having self managed teams is a good way to change this reality but to make people capable of managing their own work is a tricky task. With that in mind, the principles I consider most important to achieve it are:
1) Shared vision
The first step to build a self managed team is sharing the project goals. A good start is to define SMART (Specific, Measurable, Achiveable, Realistic, Timed) goals and to make sure that the goals make sense for the whole team.
2) Commitment
Once the vision is clear, the next step is to build the commitment. When the members of the team agree to work to achieve the defined goals, the perception of the their actions changes and they start thinking about the best solutions to get closer to the goals.
3) Trust
If people trust each other, a bond is created and there’s no reason to control other people’s work. On the contrary, people start helping each other.
4) Support
Every self managed team needs an “interface” with the rest of the organization. That’s why one or more people should be able to help when the solution to a problem depends on external factors. These people should be considered part of the team since they share the vision, are committed and trust the other members of the team.
Conclusion
Although these principles look very simple, they’re forgotten all the time. And they’re usually replaced by micromanagement, which on top of wasting people’s time frequently becomes the biggest cause of stress to the team.
Work
Agile, Coaching, Teams