Ivan Sanchez

We had some years to digest the Agile Manifesto. Now it seems like the next step is being defined in the Software Craftsmanship Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

We’ve been learning to produce better software for a long time so it seems natural to start asking ourselves to be more responsible about what and how we deliver it.

One of the highlights of the Software Craftsmanship Conference 2009 came from outside the original programme. Someone had the excellent idea of proposing the following topic for an open space session: “Why I hate frameworks”. It was enough to get my attention and before I realised the room was so full that people had to sit on the floor to be able to participate.

The discussion obviously started with frameworks for Java. It seems everyone agrees that the enterprise culture of Java introduced a huge amount of tools many developers can’t live without even though their actual benefits are at least questionable. The next question then was whether developers should be so dependent on such tools.

On one side they allow them to think on an higher level of abstraction and follow standards shared by many other professionals. As consequence it becomes easier to find people to work on these projects, specially if the most popular frameworks were chosen.

On the other hand, this approach produces a great number of programmers who only know how to work with those specific tools without even understanding the problems that are actually being solved. Then it becomes harder and harder to evaluate if a framework make people produce more and better.

A point most people agreed is that in some cases frameworks just move the complexity from one place to another, and the productivity at the end doesn’t pay off. And in many cases when people start facing the problems brought by a framework it’s normally at a stage where abandonning it means almost recreating the whole system from scratch.

The fact that many projects are trapped by frameworks brought up the question whether developers should be looking for libraries instead. It seems there’s a lack of libraries because people prefer to develop their solutions integrated to frameworks and then reach a bigger community instead of just solving a problem in isolation and letting programmers mix and match tools to use.

At the end of the session there was no real conclusion on how justifiable is the hate towards framework. Instead, there was a common sentiment that programmers should be more responsible when choosing frameworks. And maybe a clear list of problems they are solving and comparing them with the new challenges they bring may be a good starting point.

This session was a mix of talk and coding dojo, in order to give a hands on experience following the rest of this conference’s approach. As a result, this 45-minute dojo became the shortest coding dojo I’ve organised so far.

It was also the first time I’ve tried to start a dojo with an existing piece of code. This code was simple, incomplete, naive and desperately asking for refactoring. It helped keeping the session flow since the first minute, mainly because it took only a couple of seconds for the first pair to learn the code and figure out ways to improve it.

One fact that surprised me as well was how most of the 20 people present was afraid of participate. Being at a craftsmen conference and knowing the benefits of the coding dojo, I really expected people would compete for a chance to show their skills. At our regular dojos people work in harder problems and new languages and still don’t get intimidated. Well, maybe it takes some time to overcome the fear of coding in public.

This session also confirmed my theory that the Minesweeper problem is really one of the best to introduce a coding dojo to new people: it involves simple algorithms, simple data structures and has plenty of room to apply basic OOP and TDD techniques.

Finally, here are some other resources from the session:

• Slides (quick introduction to coding dojo + randori rules)
• Minesweeper problem description
• Source code – initial and final code generated at the session; download and keep playing with it.

The next open coding dojo at Skillsmatter will happen on 9th March (Monday). The registration is already open and the discussion about the coding challenge will take place on the mailing list.

Next Thursday I’ll be running a coding dojo at the Software Craftsmanship 2009. My goal is to discuss why people should organise dojos at their companies and learn more about alternative approaches people are using to improve programming skills.

It seems like it’ll be an interesting event:

This conference is all about the principles and practices, and the disciplines and habits, that distinguish the best 10% of software professionals from the 90% who are failing their customers and failing their profession by taking no care or pride in their work and delivering buggy, unreliable and unmaintainable code.

If you managed to save your spot (registration are now closed), see you there!

For the people wanting to practice their programming skills, the next open coding dojo will be this Thursday (12th) at the Skillsmatter office. After presenting a very interesting kata on the last session, Danilo Sato will be conducing this dojo.

Don’t forget to register on their website and join our mailing list if you want to know more about the challenge and the session format for this session.

Having cards on the wall is one of the most basic agile practices. Writing index cards or post-its and sticking them on the wall is fun and makes the work place look cool and organized at the same time. What we can’t forget, though, is that just having them there doesn’t make any team agile. And we can tell something is going wrong…

1. When people work on features that are not on the wall
2. When there are no priorities for the cards
3. When people don’t work on the highest priorities first
4. When people work on more than one card at the same time
5. When just one person can tell the current state of a card
6. When people don’t have a clear definition of Done
7. When people have to be told what’s the next card they should be working on
8. When the wall is not constantly updated
9. When just one person updates the wall
10. When people can’t tell how they are doing by simply looking at the wall

These are clear signs that the wall is not being as helpful as it could. And if these issues are not being worked on along the way it may not take long before people start questioning the use of the wall in the first place.

In our last coding dojo, instead of a randori we had a kata prepared by Danilo Sato. He solved the Minesweeper problem in ruby in about one hour using proper TDD and stopping for questions/suggestions from the audience. Here are some of the tricks people could learn from that session:

• When working with ruby on a Mac, the RSpec bundle for TextMate is great. It has really helpful shortcuts and can easily run your specs and see your reports inside the editor.
• Rspec can be used as a TO-DO list during the development of a class. This can be done by creating pending tests as reminders of test cases to be covered. These are tests appear “yellow” state, waiting for a proper implementation.
• Autospec is also a great tool for TDD. Seeing a test becoming green is fun, but doing so without running it manually is way better. Specially using Growl.
• When doing a presentation using the command line, it’s easy to be tricked by font colors. They may look great on screen, but a projector may not like them.
• During TDD, it’s really important to know how to fake it. But knowing when to refactor the fake code is even more.
• Being able to create methods like “[]” in ruby can be really helpful.
• TextMate allows you to run any text file or even just a few lines of it as a ruby script . This can a good alternative to play with the language instead of using irb.
• A piece of code can sometimes be used as a good visualization tool for a problem. Here’s an example:

    it "should find neighbours around cell" do
      @field.neighbours_at(1, 1).should have(8).neighbours
      @field.neighbours_at(1, 1).should include([0, 0], [0, 1], [0, 2],
                                                [1, 0],         [1, 2],
                                                [2, 0], [2, 1], [2, 2])
    end

• It’s easy to create bugs by using “…” instead of “..” in ruby ranges.
• Multiple assignments FTW.
• jUnit should have something like nested describes in RSpec. It’s a great way to group related tests for a single class.
• Nice RSpec reports can be generated even outside TextMate by using “rspec –format html”
• In BDD sometimes makes more sense having multiple assertions inside the same test. The condition in this case is that they should all help to verify a single behavior of the class being tested.
• Being able to refactor a field into a method without having to care about the references to that field is really cool.
• Assertions for boolean values in rspec are very elegant.
• The pending feature in rspec can really good for big refactorings. It helps to be sure a test or more should be failing during the process.
• Creating your own matchers can make a rspec test more readable. And people should use this feature from jUnit more too.
• It’s easy to get confused by the use of &block and yeld in ruby. In any case, it’s better to learn both and stick to only one of them whenever possible.
• Some ruby conventions are really smart. Append “?” to describe a boolean method, or “!” to do the same for a method which changes the internal state of the class.

If you want to check the source code it’s available on github. To know more about the dojo and or attend our next session check our mailing list for the discussions going on.

Yesterday we had our first dojo in 2009 and once more people asked me when are the next sessions. So here they are:

• Wednesday, January 28th
• Thursday, February 12th
• Wednesday, February 25th
• Monday, March 9th
• Wednesday, March 25th

The dates may change (they already did), so that’s one more reason to join our group or subscribe to this blog to be informed if that happens.

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.