For this dojo, instead of working on a challenge from scratch, we’ll start from an existing solution and try to improve it.
The starting point will be the Minesweeper implementation created on a previous coding dojo. It contains only 272 lines of Java code (source + tests) and a lot of room for improvement.
Some guidelines for the session:
- Two programmers will work on the code for 7 minutes. After this period, one of them switch his place with someone from the audience.
- The pair decides their next step and make sure the audience understand what they’re doing. Discussion with the audience is acceptable, but the final word is always from the pair.
- The pair should follow the 3 Rules of TDD:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
- At the end there will be a retrospective to identify all the lessons learned.
This coding dojo will take place on the 25th March and to participate you need to register at the session page on the Skillsmatter website. If you want to start playing with the code now, it can be downloaded here.
See you there!
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.