I saw a great share (by @jurgenappelo) a little while ago in my Twitter stream (I am so glad that I got a new twitter account, I can actually keep track of my stream now). It was a post by Krishna Kumar on his blog Though Clusters regarding his views on the problem with the software craftsmanship concept. Now, I am a big believer in the idea that software development is a craft and that you can hone your skills and become increasingly good at it year after year (i.e. become a master craftsman in time). While I could see where Kumar was coming from with his post and while it certainly might appeal to the vanity of the younger developers out there (myself included I guess), I am forced to disagree on several important points.

Firstly, it is certainly possible for a young developer to create great tools, products etc. and do something more experienced developers did not. But this has nothing to do with craftsmanship, it is all about having a great idea and having enough drive (and yes even talent) to make your idea a reality. This is entrepreneurial spirit, it’s capitalism, and while your new idea may appeal to the masses, it does not stop the code behind your idea from being a total mess. Craftsmanship does not even come into the picture.

What about all the new technologies and tools that are available to the young developer? Thing is, all these technologies are also available to the older developers. This industry does not reward resting on your laurels. If an experienced developer, stops learning and improving, he is pretty much guaranteed to become outdated in short order. But, no developer who aspires to be a craftsman would ever allow himself to stagnate and therefore they are just as well equipped with all the latest tools and trends as the youngsters The difference is, they have years more experience learning to be a craftsman in their profession and so their ability to apply these new technologies and skills is that much greater.

The interesting thing about our industry is that truly new and innovative ideas don’t really come along all that often. Most of the time the ‘flavor of the months’ technology is not a breakthrough, but is instead just an updated execution of an older concept using all the latest widgets and buzzwords. If you’ve been around long enough (I don’t mean just existing I mean proactively in the thick of things learning your craft) you start to see the parallels and patterns and so your ability to use and abuse these ‘new’ technologies is almost infinitely greater than someone who is seeing the concept for the first time.

What about simply writing clean, nice code and doing it quickly and well. While I would love to say that anyone can do it no matter how ‘old’ they are, I would be lying if I did. Any developer who has ever looked at code they themselves wrote 1, 2 or 3 years ago will tell you that this is one skill that you can hone and improve until the day you, errr – become a manager (don’t bite my head off, i am only kidding :)). The point is, having a skill that you can continue to improve for as long as you’re able is the very definition of craftsmanship.

What about soft skills, I mean, being a developer is not all about technology and writing the next Facebook or Twitter. Some of us need to work in teams, communicate with customers  and managers, be able to give and take feedback, be able to mentor and be mentored etc. Sure some people have these skills naturally but they are the exception, the rest of us learn this over time and hopefully get better at it (although many never do). And here once again an aspiring craftsman will have an advantage over the freshly minted youngster. This is not only true in our profession, but in any field, soft skills take years to develop.

And so I come to my final point. One of the great things about our industry is the possibility that as a relative junior you have it in you to create something truly remarkable and will appeal to many people. It is also one of the great problems that our industry faces because things that appeal to the masses inevitably become products and teams of more experienced craftsmen (and women :)) come in to work on these products. At which point they start fighting a loosing battle against the software that in many cases is spaghetti code. Badly designed, badly put together without any regard for the patterns and practices that some have been trying for years to instill into the zeitgeist of our industry. It is both the beauty and the curse of software that something which is constructed and designed so badly, can bring so much value.

My great-grandma always used to say that you don’t carry knowledge around in a backpack, meaning that more knowledge is never a burden. It might get outdated, but it will never be useless, the lessons you learn are always applicable you just need to see how to apply them. Becoming a master craftsman developer is all about learning how to apply everything you know to your current problem, the more you know the more angles you see, which lets you come up with more elegant, cleaner, faster, better solutions. It is possible for people without the same experience to come up with the same solution, sometimes it will be by accident, other times they will simply be exceptionally talented people. These however will be rare cases and will certainly not be the rule. This is why I try to learn something new every day, try to increase the depth and breadth of my skills, not just in software but in general, it all helps. I would encourage all young developers to foster the same attitude, not because you want to join some mythical elite but simply because you want to be as good as you possibly can be at what you do. And I guarantee that no developer who aspires to be a craftsman would ever lord their skills over those more junior (or less skilled). You don’t differentiate yourself based on years in the industry, you differentiate yourself on your attitude, your passion, your knowledge, your insight and your expertise – experience just tempers all these and makes them more potent. But if you never had these (or tried to develop them) in the first place, no amount of experience will help you find them. That’s what the concept of software craftsmanship is all about.

And just as a quick addendum to the above, I am a 27 year old software developer, so don’t think that what you read above is a dinosaurs view of the world (even in software 27 is not that old :)).

It occurred to me the other day that Model Driven Architecture (MDA) is a lot like waterfall processes. For those of you who don’t know, MDA is a kind-of different approach to writing software systems. Basically the idea is to define a software system in a platform independent way (e.g. using some kind of DSL for example) and then once the system is fully defined your MDA tools will be able to generate a platform specific version of your system which you can then deploy and run (yeah as simple as that :)). To simplify it even more, the MDA ideal is to be able to represent a system diagrammatically (i.e. draw it) and then press a button and get a fully operational version of the software system that you were after. If you still need to know more there is Google or Wikipedia.

MDA has been around for a few years now, and when the idea first reared it’s head it was (like many others) touted as a potential ‘silver bullet’ solution to building software quickly and efficiently. The surprising thing is how many people have bought into this, I mean, there are companies out there who have built a business around MDA. The reason I am surprised is that waterfall processes tried to do the same thing to process, as MDA tries to do to software implementation. Any developer worth his salt knows exactly how ‘well’ waterfall processes work, so what made anyone believe that doing the same thing to actual implementation of the software system would be any more successful?

How Are MDA and Waterfall Similar?

Waterfall processes try to fully define all the steps needed to create a software system from a process perspective. They attempt to create a perfect roadmap that will cover every contingency you’re likely to encounter when building a software system. The great delusion here is the fact that no-one can ever fully take into account every possible combination of domain, people, circumstances, organizational differences, etc. and did I mention people. Of course it quickly became apparent that no process can create a perfect roadmap for all those reasons. Although when I say quickly I mean it in cosmic terms a veritable blink of an eye – in human terms it was a few decades. And it will take a few more before we put waterfall processes in the grave where they belong.

What MDA tries to do is to create an abstraction of the system you’re trying to build. It is either a visual abstraction or a DSL based one, either way it is still an abstraction, you then try to generate a system based on this abstraction. Leaving aside any issues related to deploying what you generated, in order for your system to do what you need; your abstraction would have had to be spot on. So, in essence you’re trying to create a perfect system metaphor. I am not sure if that’s an oxymoron, but I do know that I’ve never been able to come up with a perfect metaphor for anything, and I don’t know anyone who has.  But, that is exactly what we’re striving towards when we do MDA, while the metaphor holds up, everything is fine, but a soon as it breaks down – as it must, what do we do?

What DO We Do When The Metaphor Breaks Down?

We do the only thing we can do, we go back to the tried and true. We crack open an editor and try to fill in the gaps by hand. But of course we can no longer use our DSL for this or our nice picture, we must work within the bounds of our platform. And this of course is where the system gets orders of magnitude more complicated. MDA tools generate the platform specific version of our system so we must find a way to hook-in our little ‘abstractional patches’ into the generation process. And of course we need to make sure that it all still fits together as the system evolves. Not to mention the fact that it is really difficult to visualize how our patches fit into the overall architecture (since we are now trying to fit a little bit of reality into an abstraction and we’re just not wired to do that easily). And should I even bother to mention that we’re no longer platform independent!

What you end up with is an environment where the further you go along the more you feel like everything is a little bit out of control. In reality it may not actually be as bad as some systems that are developed in the normal way (should I say ‘traditional’ – I better not :)). But you can’t keep the two separate representations of parts of the system in your mind at the same time and that creates a very real sense that you can’t quite get a handle on what you’re doing.

All this brings us back to me being really surprised that MDA got even the little bit of traction that it does have. We had an almost perfect example of a situation where a similar solution just didn’t work (waterfall processes), more, it was pretty much in the same domain. But that’s the thing, what we had was an abstraction, a metaphor if you prefer, it was a good one but it wasn’t perfect and so many of us missed it and MDA was born – so I guess I shouldn’t really be surprised. We’re not incompetent though, we’ve twigged on to the fact that waterfall is not the way to go and so it is going the way of the dinosaur; MDA is going to go the same way – eventually. It just that is takes us a cosmic eye-blink to get our act together.

Design sessions is one practice that most agile teams will find themselves engaging in from time to time. For some teams it will be completely informal (just get everyone together for 10-15 mins whenever you think it is warranted), for others it becomes more of a ritual where most non-trivial features get a once-over in a design session before implementation proceeds.  There are many benefits to having regular design sessions with your team mates:

• an opportunity to share knowledge about a particular area of the system with the whole team
• an opportunity to validate design decisions before implementation gets too far
• promotes collective ownership of code as everyone has some stake in most non-trivial design decisions
• gives an opportunity to brainstorm (brainstorming is not used nearly enough)
• an opportunity to identify areas that are potential refactoring candidates
• gets everyone more personally invested in the solution
• gives people a break from cutting code and gives them an opportunity to engage in an alternative but still useful activity
• an opportunity for the team to bond and ‘gel’ further

At least those are all the benefits that a design session SHOULD provide, but more often than not the potential of design session goes sadly under-utilised by many teams. Any sort of design session will provide some of the above benefits to some degree, however our goal as software developers and agile practitioners should always be to get the maximum benefits from all the practices we employ. So is there anything we can do to ensure we get the most out of a design session?

A Typical Design Session Scenario

A typical design session is a pretty informal affair and usually occurs when a pair would like some input from the rest of the team into the best way to implement the feature they are currently working on. When a pair calls a design session the rest of the team gathers in one place (usually in front of a whiteboard) where the team would proceed to outline the problem they are looking at as well as potential solutions that they have come up with. The pair running the session would normally use the whiteboard as a visual aid to help represent the problem and their solution (or solutions).

Ideally the rest of the team would have some insight into the problem and would offer better solutions or critique and improve the solutions that the pair running the design session has proposed. After some back-and-forth a solution that most people are happy with would emerge and everyone goes back to what they were doing before while the pair that called the session proceeds with the implementation.

While there is nothing overtly wrong with this scenario (and many teams would do well to even have that as one of the practices they follow), I believe there are many opportunities lost when a design session similar to the above occurs:

• not everyone is an extrovert and since no particular effort was made to engage the more introverted people their knowledge/ideas may go unheard/unused
• it takes a while to switch mental gears, since no particular effort is made to snap everyone out of the mode they’re thinking in, interesting ideas/solutions may not occur to some people until long after the design session is over
• only visual clues (whiteboard) and audio (verbal explanations) are used to represent the problem and the solution, many people work better with tactile clues (use physical objects to represent the problem), or by seeing themselves as part of a larger abstraction (acting it out)
• by presenting a solutions at the start, potential creative solutions are stifled as it puts the team into an analytical mode (analysing the presented solutions) rather than creative mode (coming up with innovative solutions)
• design sessions can sometimes be a serious affair and so an opportunity for “play” (while still doing something productive) is lost (this is a fluffy one but worth a mention I think), a design session can be light-hearted while still providing all the value

A Much Better Design Session

A pair calls a design session in very similar fashion to the above. However before jumping into the problem, call for someone from the team a tell a joke or tell one themselves. It is unexpected in a work environment and will force people  to snap out of thinking about what they were just doing, it is also a playful start to the discussion which I think is never a bad thing as it gets everyone more relaxed. This also has the potential to turn into a design session ritual that everyone on the team can look forward to which will be something they share that brings the team closer together.

Before we draw the problem on the whiteboard, we explain it using just words and then we try and represent the problem using a tactile abstraction (i.e. build what you mean using lego blocks or chess pieces or anything that people can move and touch). This gets people thinking about the problem domain before you draw it i.e. forces them to think about it before seeing it in a familiar medium. The other thing you can do at this point, either before or after drawing, is to act the problem out using people as objects in the system. Many people learn and appreciate problems a lot better by actually doing rather than seeing or hearing about it. As an added benefit, this provides another opportunity for play, gets the less extroverted people more relaxed in a fun and friendly atmosphere and gets everyone primed to participate.

Do not present potential solutions you have come up with to the team, get the team to brainstorm first and come up with solutions of their own. Chances are they will probably come up with something similar to what you had, but they will have a lot more stake in it having thought it up rather than just validated the solution that the pair that called the session contributes. By not forcing your potential solution on the team you also have a much better chance of the team coming up with something truly innovative that you haven’t thought of (remember it’s analytical thinking – validating a solution, vs creative thinking – brainstorming a solution). Of course if noone can come up with anything interesting present your solution, you don’t want to get stuck in design paralysis.

At this point everyone discusses and agrees on a way forward and the design session is concluded. The difference is:

• the team was a lot more engaged
• everyone had fun
• people had a break from the routine
• everyone was heard (there were no chickens in the design session, only pigs)
• everyone goes back to their work feeling a lot more fulfilled
• the team has bonded together that little bit more

[

](http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/)

At The End Of The Day

I have very strong opinions on design sessions. I believe they are an extremely valuable tool in the arsenal of any agile team. However I also believe that unless you can fully engage everyone on the team (who is present at the design session) and get everyone thinking creatively (and potentially in a different mode than they would normally) you’re wasting a large part of the benefit that a design session can provide. Do you use design sessions in your team (if so do you use them as fully as you can) and do you get a lot of value out of them? I’d love to hear what other people have to say on the matter.