Last monday we met at SoundCloud, this time to discuss "What is Software Craftsmanship?".
We did a fishpool discussion with 8 Seats in the middle, who wants to contribute to the discussion, may take a seat and have their say. That way different people voiced different opinions and viewpoints.
One of the first questions posed was, how do Agile Development and Software Craftmanship differ at all?
In the opinion of the discussion participants Agile Development is more concerned with managing work, while Software Craftsmanship is more concerned with, how you as a developer can deliver good work. An important part of this, that probably every developer knows, is to argue against your boss about quality vs. speed. How do you react if the business side puts you under pressure to deliver faster, reducing quality?
There are a few motivating speeches by Uncle Bob urging us to not compromise on quality, lest people will die. For most craftsmen here in Berlin this is a bit difficult to relate to their everyday situation. If faults happen in, for example, an internet shopping system, nobody will die. However, companies may lose money and even get into serious financial trouble. Who has not witnessed (and hopefully left early enough) how slower and slower development cycles bring a business to a grinding halt?
There are also some very visual metaphors about writing tests being similar to a physician washing his hands before an operation - no serious patients would ask a physician to not do it. But this metaphor is difficult to relate to software development. In the physician case you may get sick from an operation so it is easier to understand. But how do you make software quality problems visible to your managers?
This is sort of the key point of Agile Development: It wants to make quality transparent and visible to all participants. Management can see, how many features can be implemented in each iteration.
A Craftsman from SoundCloud added, that they often use graphs and charts with, for example, HTTP error rates, to show their management that there are quality issues that need to be dealt with, before new features can be added. There was general agreement, that a good craftsman is able to make it clear, in a transparent, management-understandable, non-technical way.
Charts and graphs that visualize quality, together with business-language like "This features would take a week now, but if we refactor 4 days it will only take 1 day to implement" or "If we refactor the architecture we can serve 2x as many requests with the same hardware", were generally viewed as appropriate to convince management of refactorings. The alternative is to do submarine refactorings: The team refactors without telling management, hoping the time gained balances the time spent on it. This might work, but who seriously likes to work that way?
Sharing is one of the pillars of Software Craftsmanship. The most important part of sharing, that we identified, is to teach junior programmers the tools of the trade. One fellow Craftsman said the most important thing he was taught is discipline: To write tests, to learn new things regularly, to try to improve his skills. This sort of apprenticeship happens in many companies, but often it is more by accident than on purpose. But we think, teaching new developers the values of Software Craftsmanship is probably this most important thing part of Software Craftsmanship.
Learning is the next pillar of Software Craftsmanship. The most difficult thing about learning is probably finding the time next to your day job. One fellow told us of his colleauge, who goes to India every year for 3 months to learn new coding skills (because it is cheaper to live in India). This is probably not feasible for everyone. However, Martin remarked that a lot of companies are willing to give you time to improve your development skills, simply because of the shortage of good coders. They think, if they do not give you your freedom, you are likely to search for another job. You just have to ask for it.
As an example, another craftsman told us he simply asked senior developers to review his code, so he could get suggestions for improvements and that was no problem at all. Another craftsman suggested an interesting way to improve your skills: www.codewars.com. We will probably try it out one of the next times.
Afterwards we did the TicTacToe Kata again, optionally with constraints. A few of us managed to nearly complete it without using loops and conditionals.