Software Craftmanship Sample by Sandro Mancuso

Software CraftsmanshipProfessionalism Pragmatism Pride

Sandro Mancuso

This book is for sale at http://leanpub.com/socra

This version was published on 2014-03-10

This is a Leanpub book. Leanpub empowers authors andpublishers with the Lean Publishing process. Lean Publishing isthe act of publishing an in-progress ebook using lightweighttools and many iterations to get reader feedback, pivot untilyou have the right book and build traction once you do.

2012 - 2014 Sandro Mancuso

http://leanpub.com/socrahttp://leanpub.comhttp://leanpub.com/manifesto

Tweet This Book!Please help Sandro Mancuso by spreading the word about thisbook on Twitter!

The suggested tweet for this book is:

Reading Software Craftsmanship: Professionalism, Pragmatism,Pride by @sandromancuso https://leanpub.com/socra#socrabook

The suggested hashtag for this book is #socrabook.

Find out what other people are saying about the book byclicking on this link to search for this hashtag on Twitter:

https://twitter.com/search?q=#socrabook

http://twitter.comhttps://twitter.com/search?q=%23socrabookhttps://twitter.com/search?q=%23socrabook

This book is dedicated to my beautiful wife and wonderfuldaughter. Viviane and Olivia, I love you to bits.

Contents

1 Preface . . . . . . . . . . . . . . . . . . . . . . . . . 1About This Book . . . . . . . . . . . . . . . . . . . . 5

2 Software Craftsmanship . . . . . . . . . . . . . . . 7A better metaphor . . . . . . . . . . . . . . . . . 7

What does Wikipedia say? . . . . . . . . 8A more personal definition . . . . . . . . 8The shortest definition . . . . . . . . . . 8

Beyond definitions . . . . . . . . . . . . . . . . 9Craft, Trade, Engineering, Science or Art . . . . 9

A bit of history . . . . . . . . . . . . . . . . . . . . . 11The Software Craftsmanship Summit . . . . . . 13Crossing borders . . . . . . . . . . . . . . . . . 14Craftsman Swap . . . . . . . . . . . . . . . . . . 15Software Craftsmanship Communities . . . . . . 17

The Software Craftsmanship Manifesto . . . . . . . . 18The Manifesto . . . . . . . . . . . . . . . . . . . 20Software Craftsmanship Values . . . . . . . . . 21The problem with the manifesto . . . . . . . . . 28

3 The Software Craftsmanship Attitude . . . . . . . . 30Who owns our career? . . . . . . . . . . . . . . . . . 31

CONTENTS

Employer / Employee relationship . . . . . . . . 33Keeping ourselves up to date . . . . . . . . . . . . . . 34Know whom to follow . . . . . . . . . . . . . . . . . 39

Social media . . . . . . . . . . . . . . . . . . . . 40Practice, practice, practice . . . . . . . . . . . . . . . 40

Katas . . . . . . . . . . . . . . . . . . . . . . . . 42Pet project(s) . . . . . . . . . . . . . . . . . . . 43Open Source . . . . . . . . . . . . . . . . . . . . 46Pair programming . . . . . . . . . . . . . . . . . 47

Socialise . . . . . . . . . . . . . . . . . . . . . . . . . 49Deliberate Discovery . . . . . . . . . . . . . . . . . . 50

1 PrefaceAt the beginning of my career, back in the nineties, I joined alarge international company. Although I was young, I alreadyhad a few years of coding experience. Youth, combined with a bitof experience, ensured arrogance became part of my personality.I thought I was extremely good and as soon as I joined thecompany I heard about a team that was supposedly one of thebest in the company, if not the best. The team was lead by anincredible guy that besides being amanager was also a fantasticdeveloper. He made sure that as part of his job he would bewriting code on a daily basis. I was told this team was doingsome amazing stuff and thats exactly what I was looking for.I wanted to be among the best guys. After a few weeks in thecompany, working on a different team, I finally decided to speakto the manager of this team.

I did not really know what to expect but, as I did not havemuch to lose, why not? I waited for him to be at the coffeearea, approached him and introduced myself. I want to workfor you, I finally said. He was a bit surprised but apparently tookit in a very positive way and after a thirty-minute conversationhe asked me when I could start. Ill speak to my manager andhopefully it will be as soon as possible, I said. After a few weeksI was sitting next to my new teammates.

My first day was a Monday and my new boss came to talk tome and assign me a task. He explained me what I had to doand said he would be sitting down with me on Friday to see

Preface 2

what I had done. I was thrilled. I stayed in the office until almostmidnight, arrived very early on Tuesday and around two oclockin the afternoon I was done. I had finished my first assignmentin less than half of the time I had been given. I was feelingawesome. Well, I always knew how good I was but being ableto do that in that team, in a totally unknown code base, was ahuge achievement.

I rushed to my boss office and said with a big smile in my face,Its done. I finished it and it is working. He stopped typing andturned tome. Making things work is theminimum I expect fromsomeone that is paid to do the work. he calmly said. If you saidyou have finished, it is implied that it works. That was like a bigslap in my face. My smile faded away a little bit but I thought,well, maybe it is just his way of saying things. He probably didnot really mean that. Sit here and lets see what youve done, hecontinued. I sat there and watched him typing in the commandline, checking in the code from the source control and openingmy single .pas file containing all my code on vi. We were usingDelphi back then and Delphi was very famous for its amazinglypowerful IDE. For me, seeing someone opening Delphi files onvi (Unix text editor) was very alien.

Come close so we can have a look at it together, he said. I hadwritten about two hundred lines of code so he positioned thecursor on the first line and started looking at the code line byline. Every five lines he would stop and say things like Do youknow what happens when we allocate and deallocate memory?Can you see here? You are allocating memory in one methodand deallocating it in another method. This is a potential risk ofmemory leak. Have you heard about temporal coupling? Can yousee this block of lines here? If you put some decent thinking on

Preface 3

it, you can reduce these eight lines into two. Do you know whathappens when you have a try / catch block this big? What aboutthe name of this variable and method? What does it mean? Haveyou ever thought that some of your colleagues, when needing tochange this code, may not have the same amount of informationand context as you have now? How would you feel if you knewnothing about this part of the code but you had to maintain it?What about this hard-coded bit here? Have you ever thought thatif we want to change where it points to we will need to open,change, recompile and redeploy the entire application? Why doyou have this piece of code duplicated all over the place? Do youknow how much we would need to keep in our heads if everysingle method were that big? What about making them smallerand naming them according to their behaviour? He went on andon.

It was just two hundred lines of code and I could not answerthe majority of his questions. Line-by-line he was looking at thecode, criticising it and explainingme how it could be better. Oncewe reached the end of the file, I was really annoyed. He wasvery calm, as if we were looking at some random code writtenby a stranger. Have you understood everything I said? Afterour discussions, do you agree with all the suggestions? Withoutsaying a word, I just nodded. Do you feel you can write codein a better way moving forward? Do you feel you know what todo now? he asked. Once again, I quietly just nodded. He thendeleted the entire file with all my code in it. Excellent. Since youstill have three days left, do it again.

I was shocked. I did not know how to react to that. I stood upand walked to the door. Sandro, he called me. From the door, Ilooked at him. How it is done is as important as having it done.

Preface 4

And with this, he turned back to his computer and started typingagain.

I was furious. I left his office without saying a word, wentstraight downstairs and outside. Who the hell does he think heis to speak to me like that? What a big egocentric bastard. Imnot working for him. Thats it. Im done with this company.Im resigning. Fuck that. While smoking another cigarette andfeeling a little bit calmer, I started reflecting about what hadhappened. He spent over one hour going through my code andexplaining to me how it could be improved. He listened to mein the few occasions I expressed a reaction and calmly showedme that either I was wrong or there were better ways. I realisedthat for the first time since I wrote my first line of code I hadfound someone that took the time to showme how to write goodcode. I had found someone that, besides being far better andmoreexperienced than me, really cared about making people better.I had found someone that cared about producing great qualitysoftware. I had found my first mentor.

After a few more cigarettes and pulling myself together, I wentback inside a different person. That day I learned I was not asgood as I thought I was. I learned how to be humble. I learnedthat I had a lot more to learn. I learned that just getting thingsdone was not enough, especially when you are working in ateam.

I worked with my mentor and that team for two and half years.Although we never used the term, I realise now that that wasmy first encounter with Software Craftsmanship. I learned alot from all those guys but the most important things were notthe technical ones. It was the attitude that my boss and all thedevelopers had. The last words he said during our first code

Preface 5

review session changed me forever. Ten years later I foundedthe London Software Craftsmanship Community (LSCC) and,his words, How it is done is as important as having it donewere one of the first pieces of text Ive added to the website andit is also printed on our t-shirts. Those words did not just makeme a better professional but also made me a better person.

About This Book

After decades andmany differentmethodologies, software projectsare still failing. Although there are many reasons why they fail,there are a few things that cannot be ignored: managers see soft-ware development as a production line; companies do not knowhow to manage software projects and hire good developers; andmany developers still behave like factory workers, providing avery poor service to their employers and clients. With the adventof Agile methodologies, the software industry made a big stepforward, but the percentage of failing software projects is stillincredibly high. Why are all these projects still failing? Why arewe so bad at delivering successful projects? What is missing?

Although the term Software Craftsmanship has been around forover a decade, it was just in recent years that it emerged as aviable solution for many of the problems faced by the softwareindustry today.

Software Craftsmanship proposes a very different mindset fordevelopers and companies. Although Software Craftsmanshipis not a methodology, it strongly recommends the adoptionof certain technical practices and disciplines, mostly the ones

http://londonswcraft.com

http://londonswcraft.comhttp://londonswcraft.com

Preface 6

defined by Extreme Programming. With a great synergy withAgile and Lean principles, Software Craftsmanship promisesto take our industry to the next level. Professionalism, techni-cal excellence and customer satisfaction are the main focus ofSoftware Craftsmanship. Changing the perception that softwaredevelopers are the same as factory workers and that softwareprojects can be run as if running a production line in a factoryis one of the main priorities in the Software Craftsmanshipmovement.

How can we become better developers? How can we deliver bet-ter software projects? With real stories and practical advice fordevelopers and companies, this book is directed to all softwaredevelopers and every professional directly involved in a softwareproject.

2 Software CraftsmanshipBefore we discuss the definition, lets describe what SoftwareCraftsmanship is not:

Beautiful code Test-Driven Development Self-selected group of people Specific technologies or methodologies Certifications Religion

So, what is Software Craftsmanship then?

A better metaphor

In a very simplistic way, we can say that software craftsmanshipis a better metaphor for software development than softwareengineering. Software craftsmanship sees software as a craft andcompares software developers to medieval blacksmiths. Appren-tices would work with more experienced blacksmiths, travellingfrom place to place and working for different masters, learningdifferent tools and techniques, improving their craft until a pointwhere they were good enough to become a master themselves.There is more to it, but bear with me for now.

Software Craftsmanship 8

What does Wikipedia say?

[Software Craftsmanship] is an approach to soft-ware development that emphasises the coding skillsof the software developers themselves. It is a re-sponse by software developers to the perceived illsof the mainstream software industry, including theprioritisation of financial concerns over developeraccountability.

I personally dont like Wikipedias definition. Its very dry andI dont think it captures the essence of what being a softwarecraftsman means to a software developer.

A more personal definition

Software craftsmanship is a long journey to mas-tery. Its amindset where software developers chooseto be responsible for their own careers, constantlylearning new tools and techniques and betteringthemselves. Software Craftsmanship is all aboutputting responsibility, professionalism, pragmatismand pride back into software development.

Software craftsmen care and are proud of their work and areextremely professional and pragmatic when it comes to itsimplementation.

The shortest definition

Software Craftsmanship is about professionalism insoftware development


This is probably the most important thing about Software Crafts-manship. If you only remember one thing after reading this book,I hope its the statement above.

Beyond definitions

I prefer to think of Software Craftsmanship as an ideology. Amind-set. It is something that somehow manages to express andgive a name to all the things that I always believed.

Many people, including myself, may say they were doing themajority of the things that Software Craftsmanship talks about:caring about what you do, always try to better yourself, beprofessional, delight customers helping them achieve whateverthey want to achieve, share, learn, practice, teach just to mentiona few.

If you have always valued the things above, that is great. You area software craftsman, even if you do not like to refer to yourselfas such. Many people I met do not really like labels or do not evenagree with the whole Software Craftsmanship metaphor. That istotally fine since I dont think labels or metaphors are the mostimportant points of this discussion. The important things hereare the things we should care about as software professionals.

Craft, Trade, Engineering, Science or Art

When I first got involved with the Software Craftsmanshipmovement, I remember having many discussions about whatsoftware development is. I originally liked to describe it as art.Then, over the years, I preferred to treat is as a craft. Manypeople that I know, including people that I really respect, do not


agree with that at all. For some, it is a trade. For others, it isengineering. Very few would say that it is a science.

Every developer has very strong arguments why software de-velopment should be qualified as art, craft, trade, engineeringor science. When listening to all the reasons why softwaredevelopment is one thing or another, many of the reasons makesense and some not so much.

Another big debate about Software Craftsmanship is about thename itself. Some people absolutely hate it. They cannot seethe point of comparing the most innovative and fast-changingindustry to something that goes back to medieval times. And yes,they may have a point.

Over the years, I joined some of these debates and spent a lot ofenergy trying to convince people why Software Craftsmanshipis a good metaphor and why software development is a craft.As I was getting more involved with it, I realised that it doesnot really matter. This is by far the least important thing weshould be discussing. I personally like the metaphor and treatsoftware development as a craft but what I really find importantand care about are the values that Software Craftsmanship triesto promote.

At the end of the day, what we all care about is to raise thebar of the software development profession, helping developers,including ourselves, to be professional software developers andnot factory workers.


A bit of history

Although Jack W. Reeves suggested that software developmentis more a craft than an engineering practice in 1992, I believethat Software Craftsmanship really begins with The PragmaticProgrammer: From Journeyman to Master book by Andy Huntand Dave Thomas in 1999. In 2001, Peter McBreen publishedSoftware Craftsmanship: The New Imperative, the book thatintroduced the majority of the ideas that were used to shape thewhole Software Craftsmanship movement years later.

In the Spring of 2002, Ken Auer hosted a Software Appren-ticeship Summit in North Carolina, and invited, among a fewothers, Pete McBreen, Ron Jeffries, Robert Martin (Uncle Bob),Micah Martin, Nathanial Talbott and Daniel Steinberg. At thetime Ken Auer was already hosting apprenticeships. The con-clusion of the summit was a call to action to form a commu-nity around software apprenticeship, though it didnt seem tocarry much traction. But it did change the attitude at ObjectMentor, the company founded by Uncle Bob. From there on,Object Mentor started taking on apprentices. There wasnt muchformality or process in it, but several people did go through anapprenticeship at Object Mentor, including Paul Pagel.

At Object Mentor, Micah Martin (Uncle Bobs son) had theprivilege to teach courses to dozens of developers around theworld and while instructing courses, he would often talk aboutSoftware Craftsmanship. In one of these courses, Micah metDave Hoover, who a few years later wrote a great book on

http://en.wikipedia.org/wiki/The_Pragmatic_Programmerhttp://www.amazon.co.uk/Software-Craftsmanship-Imperative-Pete-

McBreen/dp/0201733862/ref=sr_1_1?s=books&ie=UTF8&qid=1283437984&sr=1-1

http://en.wikipedia.org/wiki/The_Pragmatic_Programmerhttp://en.wikipedia.org/wiki/The_Pragmatic_Programmerhttp://www.amazon.co.uk/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862/ref=sr_1_1?s=books&ie=UTF8&qid=1283437984&sr=1-1http://en.wikipedia.org/wiki/The_Pragmatic_Programmerhttp://www.amazon.co.uk/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862/ref=sr_1_1?s=books&ie=UTF8&qid=1283437984&sr=1-1http://www.amazon.co.uk/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862/ref=sr_1_1?s=books&ie=UTF8&qid=1283437984&sr=1-1


software apprenticeship.

In the autumn of 2006, 8th Light was created by Micah Martinand Paul Pagel as an embodiment of the Software Craftsmanshipvalues. The 8th Lights founders called it a software craftsman-ship company from the start, aiming to hire through appren-ticeships and to cultivate disciplined talent. 8th Light employedSoftware Craftsmen, not developers, and their actions did not gounnoticed.

Around the same time 8th Light was created, Dave Hoover took aposition at Obtiva (acquired by Groupon in August 2011). Shortlyafter 8th Light touted their apprenticeship program, Obtiva be-gan offering apprenticeships as well. So began a friendly rivalry.

Although there were a few companies in Chicago embracingSoftware Craftsmanship, from Pete McBreens book in 2001 to2008, nothing really major happened in relation to SoftwareCraftsmanship. It was almost like if the rest of the world didnot even notice. Agile was the new thing, with many disciplines,methodologies and techniques that would shake the foundationsof the software development industry. Back then there wasnot a real need for Software Craftsmanship since many peoplebelieved that the biggest problems in our industry were beingaddressed by one or a combination of Agile methodologies andpractices.

In August, 2008, during his keynote speech at Agile 2008 con-ference, Uncle Bob proposed a fifth value for the Agile Mani-festo namely Craftsmanship over Crap. He later changed hisproposal to Craftsmanship over Execution. Also in August

http://www.8thlight.comhttp://agilemanifesto.org/

http://www.8thlight.comhttp://agilemanifesto.org/http://agilemanifesto.org/http://www.8thlight.comhttp://agilemanifesto.org/


2008, he published Clean Code: A Handbook of Agile SoftwareCraftsmanship and later in May 2011 The Clean Coder: A Codeof Conduct for Professional Programmers, two of the mostinfluential, if not the most, books in the Software Craftsmanshipcircle.

The Software Craftsmanship Summit

In 2008, after seven years since the Agile summit, it startedbecoming apparent that things in the Agile world were not goingas well as expected. The deviation from the technical disciplinesof Agile like Extreme Programming and the commercialisationof the process-oriented disciplines like Scrum started to bothersome of the Agile originals.

There was already lots of rumbling about Software Craftsman-ship in the Agile community and that led Micah Martin and PaulPagel to organise a Software Craftsmanship summit in orderto formalise and better define it. The main goal was to put apublic face on Software Craftsmanship. The invitees were allpeople that had expressed interest, to some extent, in SoftwareCraftsmanship. Paul did a good job planning activities so thateveryone would be involved.

The summit took place on December 13th, 2008, in Libertyville,Illinois, just a few kilometres from Chicago. The summit lastedfor six hours and there were roughly 30 people there includingUncle Bob, Brian Marick, Corey Haines, Dave Hoover, DougBradbury, David Chelimsky, Paul Pagel and Micah Martin.

http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1

http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1

http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1355345952&sr=8-1


Almost immediately after the summit, the conversation wastaken to the Internet via a google group. A few people fromEngland like Enrique Comba and Jason Gorman jumped rightin and had plenty to contribute and, bit-by-bit, Software Crafts-manship started spreading in the UK, Europe and later to manyother countries around the world.

In March 2009, after loads of debate, a summary of the generalconclusions was decided on. It was presented publicly, for bothviewing and signing, in the form of a Manifesto for SoftwareCraftsmanship.

Crossing borders

In February the 26th, 2009, the first international Software Crafts-manship Conference was held in London. Also in London, onMay 2009, Adewale Oshineye held a seminar for the aspiringsoftware craftsman and Enrique Comba Riepenhausen startedThe Wandering Book, a book that travels from craftsman tocraftsman capturing the current thinking, the Zeitgeist, of theSoftware Craftsmanship movement. Software craftsmen aroundthe world wrote their thoughts about that it meant to be a soft-ware craftsman and then mailed it to other software craftsman.The craftsman writing on the book would also take a pictureof their entry and post it on a website. Unfortunately, aftertravelling around a few countries, the book was lost and thewebsite got wiped out. It is still possible to find some informationabout The Wandering Book in a few blog posts. In August

https://groups.google.com/group/software_craftsmanshiphttp://manifesto.softwarecraftsmanship.org/

https://groups.google.com/group/software_craftsmanshiphttp://manifesto.softwarecraftsmanship.org/http://manifesto.softwarecraftsmanship.org/https://groups.google.com/group/software_craftsmanshiphttp://manifesto.softwarecraftsmanship.org/


2009, the first Software Craftsmanship North America (SCNA)conference was held in Chicago.

In October 2009, the book Apprenticeship Patterns: Guidance forthe Aspiring Software Craftsman, by Dave Hoover andAdewaleOshineye, was published. This book was one of the first booksto instigate, with practical advices, software developers to lookafter their careers, pursue mastery and love their profession.

From 2009 onwards, Software Craftsmanship Conferences havebeen held, every year, in the United States, United Kingdom and,since 2011, in Germany as well.

Craftsman Swap

In April 2009, 8th Light andObtiva (nowGroupon) experimentedwith a craftsman swap in Chicago. The Chicago Tribune cov-ered this event on 15 June 2009 mentioning many of the impor-tant details about the swap. There was a mutual respect betweenthe two companies, in terms of their technical capabilities, whatmade them believe they could learn a lot from each other. Manypeople, as a first reaction, would think this is utter madness butin reality, it shows that these companies have a different way ofseeing things. I look at it as not really competing against eachother but against the people out there [whose] main goal is justto make as much money as they can just pushing out softwarereally fast without thinking about how software lives over a longperiod of time, said Corey Haines, who helped to organise theswap and was the originator of the idea.

http://www.amazon.co.uk/Apprenticeship-Patterns-Guidance-Aspiring-Craftsman/dp/0596518382/

http://articles.chicagotribune.com/2009-06-15/news/0906140126_1_software-8th-light-perspectives

http://www.amazon.co.uk/Apprenticeship-Patterns-Guidance-Aspiring-Craftsman/dp/0596518382/http://www.amazon.co.uk/Apprenticeship-Patterns-Guidance-Aspiring-Craftsman/dp/0596518382/http://articles.chicagotribune.com/2009-06-15/news/0906140126_1_software-8th-light-perspectiveshttp://articles.chicagotribune.com/2009-06-15/news/0906140126_1_software-8th-light-perspectiveshttp://www.amazon.co.uk/Apprenticeship-Patterns-Guidance-Aspiring-Craftsman/dp/0596518382/http://www.amazon.co.uk/Apprenticeship-Patterns-Guidance-Aspiring-Craftsman/dp/0596518382/http://articles.chicagotribune.com/2009-06-15/news/0906140126_1_software-8th-light-perspectiveshttp://articles.chicagotribune.com/2009-06-15/news/0906140126_1_software-8th-light-perspectives


Initially there were some concerns from both sides in howit would work contractually but we were all very excited,said Tyler Jennings from Obtiva. We were expecting to cross-pollinate development practices and to give our developers anexperience they couldnt get anywhere else. We chose [to send]someone who was both an experienced developer and someonewe thought represented the Obtiva way well.

The developers involved in the swap worked as normal devel-opers, pairing with other developers and doing real work. Theywrote code, went to meetings and just pretended they wereworking for the other company for a week. This helped themto learn new process, new development styles, new languages,new tooling, etc.

Every company I know that has done one wants to do another.The benefits to the company were small in the direct sense, buthuge for the engineers who participated and the community.said Tyler. During the conversation I also asked him if he wouldrecommend other companies to do the same and if he had anyadvice. Yes! he said. It makes a ton of sense for software devel-opment companies to do these, especially if theyre not in directcompetition. It works especially well for consultancies, as wedont have many issues around intellectual property that mostorganisations do. I believe companies who do employ careful,thoughtful developers aka Craftsmen should swap regularly.Theres many different ways to approach a problem successfullyand it has been my experience that each group has things theydo better than the others. Swaps let two companies take the bestpractices from each to improve their own.

In my view, this was an amazing step forward for the softwareindustry as a whole. Initiatives like that can help software devel-


opers to get better and help companies to be more competitiveproducing better products and solutions.

Software Craftsmanship Communities

Although there was some noise about Software Craftsmanshipsince 1999, it was in 2008 / 2009 that it flourished. Besides booksand a few conferences, the Software Craftsmanship movementreally gained traction with the creation of a global mailing listand quite a few Software Craftsmanship communities in UnitedStates and Europe.

In December 2009, the Israeli Software Craftsmanship Commu-nity was founded by Uri Lavi. In August 2010, David Greenand I founded the London Software Craftsmanship Community(LSCC).

Following SoCraTes 2011, the Software Craftsmanship and Test-ing conference in Germany, several Software Craftsmanshipcommunities have been founded: the Paris Software Craftsman-ship Community was founded in October 2011, at about thesame time the Softwerkskammer started with six SoftwareCraftsmanship communities in Germany. The Germans are noworganising more than ten communities around the country.

More andmore communities are being created all over theworld.There are communities in Turku (Finland), Krakow (Poland),Stockholm (Sweden), a few in Romania, Belgium, China and

https://groups.google.com/forum/?fromgroups#!forum/software_craftsmanshiphttp://israel.softwarecraftsmanship.org/http://londonswcraft.comhttp://www.meetup.com/paris-software-craftsmanship/http://www.softwerkskammer.de/

https://groups.google.com/forum/?fromgroups#!forum/software_craftsmanshiphttp://israel.softwarecraftsmanship.org/http://israel.softwarecraftsmanship.org/http://londonswcraft.comhttp://londonswcraft.comhttp://www.meetup.com/paris-software-craftsmanship/http://www.meetup.com/paris-software-craftsmanship/http://www.softwerkskammer.de/https://groups.google.com/forum/?fromgroups#!forum/software_craftsmanshiphttp://israel.softwarecraftsmanship.org/http://londonswcraft.comhttp://www.meetup.com/paris-software-craftsmanship/http://www.softwerkskammer.de/


quite a few in United States, including Chicago, Boston, Atlanta,Utah and Seattle just to mention a few.

At the moment of this writing, the London Software Craftsman-ship Community is the largest and the most active communityin the world with almost one thousand members and aroundfour/five events per month. It also served as model and helpedmany other communities in Europe to get started.

The Software CraftsmanshipManifesto

Trying to avoid the same anticlimactic aftermath of the 2002Software Apprenticeship summit, Micah Martin really wantedsomething to come out of the Software Craftsmanship summit.He wanted something to be written down and a document ofsome kind was his goal for the summit. There they discussed,among other things, what it means to be a craftsman and anapprentice. They also discussed who the document would bewritten for, what the contents of it would be, if the documentalready existed, and if it needed to exist at all. The initial ideaswere captured on a whiteboard but although they came up withlots of good ideas, therewas far toomuch content that was far toounorganised. They werent even close to a finished document.Still, before closing the summit, Micah asked every one to signwhat they had on the white board.

Doug Bradburywent into action of his own accord. He posted theoutcome of the summit on the Google group and solicited feed-back. He got LOTS of it. In February 2009, Doug wrote an emailcalled The new Left Side which started to get the values and


wording and was refined into the actual Software CraftsmanshipManifesto. There was a debate about the agile manifesto andthe software craftsmanship manifesto that was instrumental inmoving forward with the manifesto. The discussion started withThe new left side by Doug Bradbury and Right side, revisitedby Scott Pfister.

The discussion revolved around the question Why a softwarecraftsmanship manifesto? Corey Haines addressed it saying Bybecoming a vocal community, publishing a manifesto, beginningwork on establishing principles and concrete schools of thought,we are creating a light that new developers can see. Those whoare really interested can more easily find us, talk to us aboutapprenticeships, meet companies that actively engage in crafts-manship activitiesapprenticeships, journeymen programs, etc.In some cases, this will introduce them sooner to these ideas,hopefully saving some from the frustrations they can face in adifferent situation.

It was a fascinating conversation, which spawned the finallanguage of the manifesto. The whole discussion can be readin the Software Craftsmanship Google Group. After a fewweeks, Doug presented an elegant manifesto based on all theideas discussed, with the structure of the Agile manifesto. It wasgreat, and the community in general approved it. Within anothercoupleweeks they built and published a site where people couldsign the Manifesto for Software Craftsmanship.

Paul Pagel describes the history of the Software Craftsmanship

http://groups.google.com/group/software_craftsmanshiphttp://manifesto.softwarecraftsmanship.org/

http://groups.google.com/group/software_craftsmanshiphttp://manifesto.softwarecraftsmanship.org/http://groups.google.com/group/software_craftsmanshiphttp://manifesto.softwarecraftsmanship.org/


Manifesto on the 8th Light blog.

The Manifesto

As aspiring Software Craftsmen we are raising thebar of professional software development by prac-ticing it and helping others learn the craft. Throughthis work we have come to value:

Not onlyworking software, but alsowell-crafted softwareNot only responding to change, but alsosteadily adding valueNot only individuals and interactions,but also a community of professionalsNot only customer collaboration, but alsoproductive partnerships

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

In the manifesto, the essence of Software Craftsmanship is cap-ture in its subtitle: Raising the bar. The manifesto summarisesthe values, frustrations and aspirations of very experiencedand talented developers. For them, projects had to stop failingbecause of poor management, ill processes and, of course, badlywritten code.

http://blog.8thlight.com/paul-pagel/2009/03/11/history-of-the-software-craftsmanship-manifesto.html

http://manifesto.softwarecraftsmanship.org/

http://blog.8thlight.com/paul-pagel/2009/03/11/history-of-the-software-craftsmanship-manifesto.htmlhttp://manifesto.softwarecraftsmanship.org/http://blog.8thlight.com/paul-pagel/2009/03/11/history-of-the-software-craftsmanship-manifesto.htmlhttp://blog.8thlight.com/paul-pagel/2009/03/11/history-of-the-software-craftsmanship-manifesto.htmlhttp://manifesto.softwarecraftsmanship.org/


Developers are taking the matter into their own hands and aretrying to change how the industry sees software development.They are doing that not just by proposing new and revolutionaryprocesses but also by showing their customers that they careabout what they do. Developers are showing their customersthey want to work together with them in order to produce greatand long-lived software, helping them to achieve whatever theywant to achieve.

Software Craftsmanship Values

Not only working software, but also well-craftedsoftware

Think about a 5 year old application (it could be 2 or 10). Imaginean application that has no tests, no one knows exactly how theapplication works, the code is full of technical and infrastructureterms instead of expressing the business domain, classes andmethods have hundreds, if not thousands, of lines. Also imaginethat we need to make changes to this application, but writingtests to it is a massive undertaking. Of course, we think, wecan pair with the other developers in the team. No, there is noteam. You are the team. All the developers that developed theapplication have left and you had a graduate that was hired afew weeks ago to look after the application. Sigh!

The main problem we face in applications like that is that we arescared to change some of its parts (fix bugs, add new features,etc.) because we dont understand how it works and have noconfidence we will not introduce a different bug, causing adifferent feature of the application to stop working or misbehave.


This application isworking software but is it good enough?Well-crafted softwaremeans that regardless how old the application is,developers can understand it easily, side effects are well knownand controlled, high and reliable test coverage, clear and simpledesign, business language well-expressed in the code and addingor changing features does not take longer than it used to take atthe beginning of the project, when the code base was small.

The code must be maintainable and predictable. Developersmust know what is going to happen when changing the codeand must not fear to change it. Changes should be localised andnot impact other parts of the applicationno ripple effects. In afew minutes, after pressing a button, tests will inform if there issomething broken.

In order to evolve applications, developers must not fear chang-ing them. Using Test-Driven Development, simple design andexpressing the business language in code are the best way tokeep a healthy and well-crafted code.

Not only responding to change, but also steadilyadding value

Have you ever thought about how expensive a software projectis? Think about all the developers working on it. Now thinkabout all the other professionals that are also part of the projectlike testers, production services, operations, business analysts,product owners, and project managers. Imagine how much ispaid just in salaries. Now add the cost of all the computers,

http://www.jbrains.ca/permalink/the-four-elements-of-simple-designhttp://martinfowler.com/bliki/UbiquitousLanguage.html

http://www.jbrains.ca/permalink/the-four-elements-of-simple-designhttp://martinfowler.com/bliki/UbiquitousLanguage.htmlhttp://www.jbrains.ca/permalink/the-four-elements-of-simple-designhttp://martinfowler.com/bliki/UbiquitousLanguage.html


furniture, communication infrastructure, office rent, marketing,sales, customer services, catering, cleaning and everything else.Yes, they all add up. On top of that, imagine distributed teams,multiple offices, travelling and everything else that comes withit.

Software is normally a massive investment and as a normalinvestment, companies will want a return. The reasons forcompanies to invest in a software project are: make money, savemoney and protect revenue. With that in mind, it is our job tohelp them achieve that.

Whenwe talk about steadily adding value, we are not just talkingabout adding new features and fixing bugs. This is also aboutconstantly improving the structure of the code, keeping it clean,extendable, testable and easy to maintain.

It is our job to make sure that the older and bigger the softwaregets, the more the company will benefit from it. We want tokeep adding features to the project and making the appropriatechanges to the application at the same speed that we used to doat the beginning of the project. This would allow companies toreact quickly to the market regardless how old the software is.As it gets older, software should become more valuable and nota source of pain and increased cost.

Increasing the software lifespan, keeping the ability to changeit fast enough is our main mission. Great design and automatedtesting skills, and passionate and talented developers are essen-tial to achieve that.

The Boy Scout Rule (first applied to software by Uncle Bob) statesthat we should always leave the code cleaner than we foundit. This is a paraphrase of Boy Scouts rule: leave the camp cleaner


than you found it.

The focus on high-quality software must be the number onepriority if we want long-lived applications. Totally re-writing alarge application a few years after it has been developed makesfor a very poor return on investment. In many occasions, thedecision to re-write the application is made because to cost ofmaintenance of a poorly written application is too high.

Insanity: doing the same thing over and over againand expecting different resultsAlbert Einstein

The problem is that the same bad techniques used to build theold application, will be also used to build the new applicationmaking the new application as bad as the old application aftera few months or years. It is our job to break this cyclewritingquality applicationsor at least make this cycle much longer.

Not only individuals and interactions, but also acommunity of professionals

Sharing and mentoring are at the heart of Software Craftsman-ship. Software craftsmen are passionate and always strive tobetter themselves. However, we have a far bigger mission thanthat. We believe that we are responsible for preparing the nextgeneration.

The best way to move our industry forward is by sharingwhat we learn through mentoring and inspiring less experienceddevelopers. This is also related to the idea of apprentices, jour-neymen andmasters, where software craftsmanship masters will


mentor apprentices and help them in their journey. Knowledge,ideas, successes and failures must be shared and discussed withinthe community in order to move our industry forward.

I was quite surprised to hear from some developers and Agilecoaches that the Software Craftsmanship communityor devel-opers that call themselves software craftsmenis a group of self-selected and elitist developers. A developer cannot be considereda software craftsman if he or she: thinks software craftsmanshipis about elitism; is not humble enough to learn from others; isnot willing to share his knowledge and mentor less experienceddevelopers.

From my experience, the Software Craftsmanship community isone of the most open communities I know. By its own nature,being language agnostic, it is a community that embraces all sortsof developers, regardless their level of seniority or technologythey use.

Learning from each other is by far the best way for us to becomebetter. Writing blogs, contributing to open source, making ourcode publicly available, becoming part of our local communitiesand pair programming with other developers are some of theways we can contribute to a greater good.

Since 2010, Software Craftsmanship communities are being cre-ated in Europe and the US running many free events everymonth. They welcome developers from all sorts of backgrounds,industries and level of experience. These communities promotean environment where developers can meet, share ideas andwrite code together.

Besides external communities, this item in our manifesto alsoincludes our work environment. Great developers want to work


with great developers. Great developers want to work for greatcompanies. What we want is to work with people that can makeus better, that are willing to share and learn from each other. Wedo not want mere colleagues. We want passionate and inspiringfriends.

Not only customer collaboration, but also produc-tive partnerships

The first thing to mention here is that we do not believe inemployer-employee relationship. Regardless what the contractsays (you being a permanent employee, contractor, consultant,vendor, paid per day, hour or month) that is just formalities andcan be considered a detail. We believe in partnership and pro-fessional behaviour above all. If you are a permanent employee,you should treat your employer as your customer the same wayas if you were a contractor or consultant. Employers, on theother hand, should also expect their employees to provide a greatservice at all times, like a consultant and contractor is supposedto. Turning up to work on time, keeping our heads down and justdoing what we are told to do is unprofessional.

Software craftsmen are not factory workers. We want to activelycontribute to the success of the project, questioning require-ments, understanding the business, proposing improvements andproductively partnering with their customers or employers. Thisis a different approach to the traditional employer-employeemodel and the advantages for the customers are enormous.A highly motivated team has a much bigger chance to makeany project succeed. Passionate and talented people want tosucceed and will always find ways to overcome problems andbureaucracy.


Software craftsmen want and need successful projects to buildtheir reputation. We want to be proud of our achievements.Successfully delivering high quality software and customer sat-isfaction are essential for a software craftsmans career.

Although it is one of the most important ones, we understandthat writing code well is just one of the things we need to do tohelp a project succeed. Helping our clients to have a better pro-cess, provide options, help to remove unnecessary bureaucracy,understand the business domain, question requirements, providegood information and alternatives that will help customers toplan and prioritise work, and work on things that are notcoding tasks but are equally important to the project are partof the behaviour of a software craftsmen. Providing value to ourcustomers at all levels is what we mean by having a productivepartnership.

The core business of many of our customers is not software andit is our obligation to help them run a software project in the bestway possible. Developers that say it is not their job if the task isnot code-related are not software craftsmen.

Some customers are not ready for a productive partnership

Unfortunately there are still companies out there that are notready for this partnership. They see software development as anindustrial process and the least important part of the project. Forsome companies, software developers are the same as factoryworkers, that are there just to follow orders from smarter people.

Some of these companies focus in getting the cheapest developersthey can find and will always have nontechnical managerstrying to micro-manage these developers. Some of them will notwelcome or listen to developers when it comes to business deci-


sions. Some will hire a single person, quite often with outdateddevelopment skills, to be the technical leader (or dictator).

Working for a company with this mentality is always a toughsituation for any software craftsman. We should always try ourbest to turn this situation around and help our customers to seehow we could be more helpful than just someone that can writesome code.

However, at the same time that companies, in general, want goodpeople, software craftsmen will look for good clients. There is nopoint in spending all our energy and health trying to help thosethat do not want to be helped. There is a limit to our willingnessto help our customers. Knowing how to select customers (oremployers) is also an essential skill for a craftsman. Choosinga customer that is not interested or does not value the skills of asoftware craftsman is pointless.

Choosing our customers carefully is essential for us to build ourreputation and move forward in our careers. A partnership, bynature, is a two-way street. If you do not feel that the partnershipis also beneficial to you, it is probably time to find anothercustomer.

The problem with the manifesto

There were quite a few criticisms of the Software CraftsmanshipManifesto. The main one is that, unlike the Agile Manifesto,the Software Craftsmanship Manifesto is almost impossible todisagree with. In the Agile Manifesto, the contrast between theleft and right sides is strong, clearly indicating what is beingproposed. A person that believes that documentation is veryimportant, struggles to fully accept Working software over


comprehensive documentation. Companies used to fixed-priceprojects and detailed contracts would struggle with Customercollaboration over contract negotiation. In the Software Crafts-manship Manifesto, there is no strong contrast between the leftand right sides. The right side is just an evolution of an alreadyaccepted left side. A person, that already agrees that workingsoftware is better than comprehensive documentation, will neverdisagree with the value of well-crafted software. Companiesthat already believe in collaboration will never disagree withproductive partnership.

This is a fair point. I dont think that anyone that believes inAgile can really disagree with what is written in the SoftwareCraftsmanship Manifesto. However, if noone disagrees with theSoftware Craftsmanship Manifesto, it is fair to assume thateveryone agrees with it. If that is the case, the question we shouldask ourselves is: Do we always work and behave according towhat is written in manifesto? Are we really practicing the thingsupon which we agree?

In my view, the manifesto should not be read as if it was justa bunch of lines put together. We need to go deeper to fullyunderstand it.

3 The SoftwareCraftsmanship Attitude

If we think that a significant piece of code we wrote some timein the past is still good enough today, it means we didnt learnanything during this period.

For us, software craftsmen, caring and being proud of the workwe do is a given. Constantly finding ways to become betterprofessionals is a lifetime commitment. Satisfying and helpingour customers to achieve what they want to achieve, in the mostefficient way, is our main goal. Sharing our knowledge with lessexperienced software craftsman is our moral obligation.

A few years ago, I was speaking to a colleague ofmine. We had joined the company roughly at thesame time and at the same position, and workedin a project together for almost one year. Sincewe were working for a consultancy company, aftersome time we went separate ways to work in dif-ferent projects and for different clients. It was onlyafter a few years that we had the opportunity towork together again. I asked him how things weregoing with him and he said, I dont really like thiscompany. This company sucks. I was surprised bywhat he said since I was really enjoying my timeat that company. So then I asked him why he was

The Software Craftsmanship Attitude 31

saying that. In all these years, they never boughtme a book. Never sent me on a training course andnever gave a project using modern technologies.They never gave me a promotion either, he said. Ihavent learned anything new for quite a long time,he complained.

I was not quite sure what to think and say abouthis comments. I had two promotions during thatperiod, worked on quite a few good projects andlearned many new things. Who owns your ca-reer? I suddenly asked him after a few secondsof awkward silence. He did not quite understandmy question and asked me to repeat. Who is incharge of your career and your professional future?I asked again. Even after a few years since we hadthis conversation, I still remember the puzzled lookon his eyes.

Who owns our career?

What if the company we work for does not buy us any books?What if the company never sent us to any training course orconferences? Would that be the only time where we would learnanything new? Does it mean the company is bad?

Imagine that we need a plumber to do some work in our house.Imagine that we need a solicitor to solve any legal issues wemay have, a doctor, when we are sick, or a dentist, when wehave an aching tooth. Think about our hairdressers when weneed a haircut. We normally go to these professionals when


we have a problem, so now imagine them turning back to usand saying, Could you buy me a book? Can you send me ona training course? What would we think about that? To makethings worse, imagine that we, for some really bizarre reason,decides to buy them a book or sending them on some trainingand once they acquired the knowledge we gave them, they comeback and charge us for their services as well. How does it soundto you?

These professionals need to invest in their own careers andknowledge so they can do a good job, satisfy their clients andhopefully be referred to other clients. They use their own moneyand time to keep themselves current. Those that dont will startlosing clients, receive fewer referrals and will slowly be forcedout of the business.

On the other hand, factoryworkers, for example, rely on training.Factories need to train their employees to use new machines sothey can do their mechanical and repetitive work well. However,factory workers have no saying in what machines the factoryshould buy or how they are going to do the work. They are justtold what to do.

Professionals are not paid to learn. They are expected to providea good service to their clients. They are expected to provide so-lutions, alternatives and ideas to their clients. They are expectedto help their clients to achieve whatever they want to achieve inthe best way possible and that is how they build their reputation.

Each one of us wants to be treated and respected as softwareprofessionals but before we achieve that we need to start be-having like professionals. That means that we should use ourown time and money to get better at what we do. We should


own our own careers, be in control of what we learn andwhen we learn. We should be in a position that we can helpour customers (employers should also be seen as customers), toachieve what they want to achieve. Developers that just rely ontheir companies to provide them knowledge are not professionalsoftware developers. They are just factory workers in disguise.

So companies should not be investing in their own people? youmay be asking. No, that is not what it means. Companies shouldinvest in their people but software professionals should not seethat as an obligation. That should be seen as a bonus, a win-win situation. Companies that provide time to developers to getbetter at what they do are much smarter and can become farmore efficient. Passionate developers will always favour thesecompanies when choosing who they want to work for.

Our industry moves, possibly, faster than any other industry.New languages, new frameworks, practices and processes areconstantly being created and evolving. Keeping ourselves up todate and constantly getting better at what we do is key for asuccessful career as a software craftsman.

Employer / Employee relationship

In creative work, the employer / employee model is dying. Onone hand, we have a contractual model that states how peopleshould be paid and also the legal and behavioural obligationsthat needs to be respected by both parts, employers and em-ployees. On the other hand, we have the type of relationshipthat professionals have with their customers. The old top-down,command and control style of management became very popularand strong during the Industrial Revolution and arguably still


has its merits when the majority of the work force is doingmanual or repetitive work. However, it does not work well forcreative workers. This style of management can be extremelydamaging to the morale of software professionals, making thecompany far more inefficient. Companies that are still usingthis style of management very rarely are able to hire talentedprofessionals and are slowly losing the ones they have, if any.But, of course, this is just one side of the story. Keeping ourheads down, working hard from 9 to 5 and doing only what weare told is not professional. That is what factory workers do. Ifdevelopers want to be treated as professionals, they should startacting as professionals. A software professional must, amongother things, get involved and contribute to the business, provideoptions and solutions, and offer the best service when it comes toimplementation, technologies and quality of what we produce.

The relationship between software craftsmen and their cus-tomers should be seen as a business and productive partnership,regardless of which contractual model we may have. Being apermanent employee, a contractor, a consultant or a developerworking for an outsourcing company should not affect at all thisrelationship or the attitude we have towards our customers.

Keeping ourselves up to date

We live in a world where there is more and moreinformation, and less and less meaning. - Jean Bau-drillard

Different people have different learning patterns and preferencesand by no means do I feel that I could describe all the possible


ways a person could learn. However, the following is a small listof things we can do to keep ourselves up to date.

Books, many books. Having our own library, physical or elec-tronic, is essential. We are very lucky to be in an industry whereso much information is produced. However, there are manydifferent types of books and choosing which books to read canbe a very difficult task.

Technology-specific books are very valuable but they expire.They are essential for the immediate need, when we have orwant to learn a framework, language or any other software weneed to use. They are great to give us a deep understanding ofhow things work and the knowledge acquired can normally beused immediately. They are also great when we are planningour next career steps, since they can give us details of how to usethe technologies that may be in between our desirable next joband us. However, many of the technology specific books get oldextremely quickly. When a new version of the technology theycover is released, or a different way of doing things becomemorepopular, they will not add as much value as before. Exampleswould be books about Java, Hibernate, Node.js or Clojure.

Conceptual books are the books that give us the foundation toadvance in our careers. They are the books where we get intro-duced to new concepts, paradigms and practices. The knowledgewe acquire in this type of books not always can be appliedimmediately since it may take quite a long time for us to digestthe information and become proficient. Quite often a technologyor language is used to explain the concepts but normally theknowledge we get can be applied broadly. Books covering topicslike Test-Driven Development, Domain-Driven Design, Object-Oriented Programming / Design and how the different types


of NoSQL databases could be modelled, just to mention a fewexamples, would fit in this category. Learning new concepts,paradigms and practices is far harder than learning a specifictechnology and it may take years until we get conformable withthem. However, they are the books that give us the foundationto learn specific technologies much quicker.

Behavioural books are the books that make us more efficientwhen working in teams and organising ourselves. They helpus to deal with people, clients, deadlines and team members.Knowing languages, frameworks and practices is not enoughif we want to be professionals. We also need to learn howto deal with everything else that is not related to code, butcan be the main reason why we are writing the code. Booksin this category will cover the more human and professionalside of software development and would include topics likeAgile methodologies, Software Craftsmanship, Lean SoftwareDevelopment, psychology, philosophy and management.

Revolutionary books (some call them classics) are the ones thatchanged the way we work. They propose a different set of valuesand principles, quite often firstly rejected or ignored by thevast majority of professionals. Bit by bit, they end up makingtheir way to mainstream. They are books that every softwaredeveloper is expected to have read and are constantly mentionedin technical conversations. Very rarely a technology specificbook becomes a classic. Normally the revolutionary books areconceptual, behavioural or a combination of both. Books in thiscategory define or have a great influence in the direction andevolution of our industry.


A few examples would be, The Pragmatic Programmer, TheMythical Man-Month, Design Patterns (GoF), Test-Driven De-velopment: By Example, Extreme Programming Explained: Em-brace Change and Refactoring. Books in this category are bookswhere their content may take many years to master.

Books give us a deeper understanding of a technology or subject.Favour conceptual and behavioural books for your career pro-gression, starting with the revolutionary ones. Read technologyspecific books for your short and medium term plans.

Reading itself also has a learning curve. There are many differentways to read books and understanding them can make a bigdifference in how fast we can read them and how much wecan learn. This topic is beyond the scope of this book but Irecommend you look for speed reading techniques.

Blogs are extremely popular and a great way to keep ourselvesupdate. Quite a few very good developers I know and respect justread blogs. They have almost abandoned books. Blogs tend to fitwell in the software craftsmanship and Agile models since theyare much more human, short, contain real experiences, personalfindings, opinions, successes and failures. Reading blogs frommore experienced professionals and subject matter experts isa good, quick and free way for us to learn from many greatprofessionals at the same time. There are also loads of great tools

http://www.amazon.com/dp/020161622X/http://www.amazon.com/dp/0201835959/http://www.amazon.com/dp/0201633612/http://www.amazon.com/dp/0321146530/http://www.amazon.com/dp/0321278658/http://www.amazon.com/dp/0201485672/

http://www.amazon.com/dp/020161622X/http://www.amazon.com/dp/0201835959/http://www.amazon.com/dp/0201835959/http://www.amazon.com/dp/0201633612/http://www.amazon.com/dp/0321146530/http://www.amazon.com/dp/0321146530/http://www.amazon.com/dp/0321278658/http://www.amazon.com/dp/0321278658/http://www.amazon.com/dp/0201485672/http://www.amazon.com/dp/020161622X/http://www.amazon.com/dp/0201835959/http://www.amazon.com/dp/0201633612/http://www.amazon.com/dp/0321146530/http://www.amazon.com/dp/0321278658/http://www.amazon.com/dp/0201485672/


we can use to keep track of blogs like Instapaper and Evernotejust to mention a few.

Blogs can be dangerous for the uninformed, though. The vastmajority of blogs are written without much research or deepthought. Some blog posts are just a brain dump of half-bakedideas, rants or random thoughts. Some developers use theirblogs to keep track of their own professional progression. Somereport their own experiences in real projects but that does notnecessarily mean they were able to solve their problems wellor even to identify their real problems. And that is OK. That isexactly why blogs are great. As long as we understand that weneed to read blogs with a pinch of salt, they are fantastic.

But do not think that just experienced professionals shouldwrite blogs. Software developers should have their own blogsregardless of how much experience they have. We all should besharing our experiences and findings and help to create a greatcommunity of professionals. Sometimes we may think that weare probably not good enough or not have much to say. Wemay think that we dont have an original idea and no one willread our blog anyway. First of all, we should treat our blogas a record of our own learning and progressiona history ofour thoughts, ideas and views of the world over our careers.We should not worry too much about what other people willthink about it. We should first write it for ourselves. Even ifdevelopers more experienced than us have written about thesubject many times before, it is worth writing whatever we arecurrent learning anyway. Every year there are thousands of newdevelopers joining our industry and will need to learn whatever

http://www.instapaper.comhttp://www.evernote.com

http://www.instapaper.comhttp://www.evernote.comhttp://www.instapaper.comhttp://www.evernote.com


we are learning as well. Maybe for them, our blogs will bevery useful since we will be writing it from the perspective ofa beginner. Do not worry about being judged by more seniordevelopers because that is not going to happen. Whenever weGoogle for something and the first link lead to something wealready know, we just jump to the next link. All developersshould appreciate the effort that we make to write and share ourviews, for free, with the rest of the world.

Technical websites are also good in order to keep ourselvesup-to-date with whats going in the market. There are manywebsites that work as a digital magazine, announcing new trendsand techniques. Some of these websites have technical writerswriting for them every day. Some of them just aggregate the bestblogs or are a big discussion forum.

Know whom to follow

In every profession, there is a group of people that contributemassively to move that industry forward. We have many ofthese people, some on the technology specific side and otherson the more generic, conceptual and behavioural side. They areall important, so know who these people are. That will help usto filter the entire amount of information we have online or inphysical books. For example, if we work with Java or Ruby, weshould know who publishes the best material on it. Know whois helping the language to move forward or defining better waysto use it. Know who the people that are re-shaping our industryare. When we hear terms like Agile and Software Craftsmanship,we should try to discover who are the people behind these ideas.Look at their history. See what they published. Try to understand


where they got their inspiration from or in what they based theirideas. We may discover that many of the things we talk abouttoday go back a few decades.

Social media

Learn how to use Twitter. Used wisely, Twitter can be a greattool for information gathering. Following the type of people de-scribed above and other fellow developers can be one of the bestways to keep yourself up-to-date. Whenever someone publishesa blog post, they will tweet the link. Whenever someone findssome interesting material, they will also tweet the links. Sometimes we can follow quite a few interesting online conversationsand that may be a good opportunity to join in.

There are loads of great bloggers and technical websites outthere, but it can be very difficult to keep track of all of them.Blog aggregators are also a great way to keep ourselves up-to-date. Try combining it with tools like Instapaper and Evernote,selecting whatever you find interesting and potentially want togo back to it.

Practice, practice, practice

How it is done is as important as having it done.

There is no other way. If we want to be good at writing qualitycode, we need to practice how to write quality code. Whenpracticing, the focus should be on the techniques we are using

http://twitter.com

http://twitter.comhttp://twitter.com


and not in solving the problem. Solving problems is what we arepaid for and what we do at work. However, when practicing, weshould focus on how we are solving the problem. For example,imagine you are trying to learn or get better at Test-DrivenDevelopment. TDD is a hard discipline, it is counter-intuitiveat first, and that is why we need to practice.

Remember when you were learning how to drive.I remember that every time I was driving up a hillI was praying for the traffic light not to go red. Iused to think to myself Damn, Ill need to stop,put in first gear, release the clutch slowly and becareful that the car does not stall or roll backward.I also remember the first time I had some friends inthe car and they were asking me, Can you switchthe radio on? and I, nervously glancing betweenall the mirrors, firmly gripping the steering wheel,would tell them, No. That happened because whenI was learning how to drive, I was worried aboutthe car. I was worried about the gear shifting. Iwas worried about the mirrors, other cars, drivingstraight and staying in the lane, not to drive overthe other lane when turning and so on. Now, after afew years, imagine how you drive. We do not evenremember we are in a car. We do not think about themechanics of driving a car anymore. We just focuswhere we are going, what we are going to do whenwe arrive there, we listen to music, sing along, haveconversations while driving. Driving a car becamesecond nature.


Technical practices, like Test-Driven Development, and newtechnologies are the same thing. The more we practice, the morecomfortable we become, to the point where we dont think aboutthem anymore. We just focus on what we want to do.

When practicing, we need to focus on writing the best code wecould possibly write. If it takes us minutes, if not a few hours, towrite a single test but it is the best test we could have written,that is OK. We should not worry if we take a long time to namea variable, method or class. As long as we tried our best tofind the most appropriate name for it, we should feel great. Weare practicing and when we do it, we should strive for perfectpractice. With this approach, when facing the demands of a realsoftware project, we can concentrate in finding a good solution tothe problem, and not on how to write tests or which commandsto use.

Katas

Katas are simple coding exercises. They normally have very sim-ple problem domain that can be understood in a few minutes butare normally complicated enough not to be solved too quickly.They normally take from a few minutes to a few hours to solveand are a perfect way to try new techniques and approaches. Anexample would be a kata where we need to calculate the score ofa bowling game or solve a tic-tac-toe. We can use these katas topractice things we thinkwe are not very good at, like Test-DrivenDevelopment, another language or framework.

Katas have been criticised by certain people in the Agile com-munity though. Some people say that it is plain stupid to do thesame thing over an over again. Well, to a certain extent there


is some degree of truth in it. Normally this is said because theterm comes frommartial arts and that is how it is done in karate,for example. We do the same movements over and over again.That was probably the original intent when we started using theterm kata for coding exercises. However, solving katas with ourcurrent toolkit, that means, the techniques and tools that we arecomfortable with, does not make a lot of sense.

The idea, when doing katas, is that we stretch ourselves, usingpractices, techniques and technologies that we are not verycomfortable with, with the intent of getting better at them. Afterpracticing these things quite a few times, youmay feel ready or atleast fairly comfortable to do that in a professional environment.Think about musicians that practice for hours, days and monthsbefore their live performances. That is exactly what we are tryingto achieve here.

Another very useful technique when doing katas is to do thesame kata over and over again but each time using a completedifferent approach or technique. That allows us to experimentand compare. The correct word to define this practice, accordingto martial arts, is keiko. However, as developers already adoptedthe word kata, we should keep using it instead of introducinganother term.

We can find a good source of coding katas at codingkata.org,codekata.pragprog.com and kata.softwarecraftsmanship.org

Pet project(s)

Pet projects are for me, by far, the best way to learn and study.A pet project is almost a real project but without the pressure.There are no deadlines, they do not need to make money,


you control the requirements and most importantly, you usethe technologies and methodologies you want, whenever youwant, wherever you want. You are the boss. In real projects, aprofessional software developer would first, before writing anycode or making any technical decision, understand the problemdomain. We would speak to stakeholders, product owners, users,business, marketing and whoever else is involved and can con-tribute to the business idea. These conversations, in a healthyAgile environment, should happen frequently throughout theproject. According to what the customer wants to achieve andthe scope of the project, we would then choose the most suitabletechnologies to develop the project. Pet projects are exactly theopposite. First we decide what wewant to learn and that includespractices, disciplines, methodologies and technologies. Only thendo we find a problem to solve. It is much easier to understandwhy and how we can or cannot use certain technologies ifwe have a pet project to try them. Pet projects allow us toplay, experiment, discover and learn in a very safe environment,giving us the experience we need to apply what we have learntinto real projects.

Another important thing about pet projects is that we canexperience several aspects of a real project. For example, weneed to come up with an idea. Once we have an idea, we needto start refining the features and prepare a backlog. Preparinga backlog means to think about priorities, rough estimations,writing stories, splitting tasks. We also need to think about tests,how we are going to deploy the application, version controlsystem, continuous integration, usability, user interface, infras-tructure code, design, databases. As soon as we start using theapplication ourselves, we start changing our minds about the


features (business) and also the technology choices. And that isexactly what happens in a real project.We do not need to have allthat in place, but we can if we want to. We can use pet projectsto learn any aspect of a real project. We can even try to writea business plan for it, if we want to learn something about it.Remember, we are the boss and we do whatever we want, aslong as we are learning something. Thats the whole point.

Above all, pet projects are meant to be fun. A common problemdevelopers have with pet projects is in how to find a good idea.The good news is that you do not need one. You are not startinga new business. I always advise developers to choose a subjectthat they are very passionate about. For example, if you liketravelling, try to create a travelling website. If you like running,create an application that can capture your progress, displayinggraphics, etc. If you feel you should be more organised withyour own tasks, create a mobile app where you can track andbe notified of what you need to do and when. It does not matterif there are thousands of other applications that do the same.There are always different things you would like them to do.The advantage of choosing a topic where you are emotionallyattached is that you will never run out of ideas for features orimprovements. Besides that, you will always want to work on itsince you normally will want to use it as well. All these thingswill help you to be quite close to a real project and practicingthem will have an enormous impact in your professional career.

A common question is if we ever should transform our petprojects into a real business. The answer is it depends. Inormally would say no to that since if you want to have abusiness, writing code and learn new technologies should not beyour number one priority. I would recommend that you to find


some good material and get yourself familiar with Lean Startupconcepts before writing a single line of code. The transition froma pet project to a real business can be extremely painful andfull of disappointments. Many of us get very attached to ourown applications and code base, what can makes us blind towhat the market really wants. If we feel we should transformour little Frankenstein pet project into a business, focus on thebusiness first and be ready to throwwhatever percentage of whatyou have written away if that is what the business demands.Detach yourself from the code, clean it up and leave just the bareminimum to satisfy the business needs.

Open Source

Contributing to open-source projects is also a great way topractice. There are thousands of them out there. Find a projectthat is related to what you want to learn or know more aboutand download the source code. Start running and reading thetests, if any. Inspect, debug and play with the code. If youwant to contribute, start small: add some documentation, writesome tests, check the list of bugs to be fixed or features to beimplemented, pick a simple task and give it a try. You can alsopropose and implement a new small feature to start with.

Open-source projects tend to be very different from pet projectssince they are normally, with few exceptions, very specific inscope. For example, it may be an ORM framework, a libraryto make web service calls, transaction management, social net-works integrators and so on. Although all these things areextremely important, necessary and useful, open-source projectstend to be just one of the libraries your professional applicationswill use so do not forget to see the whole picture.


Another great thing about open-source projects is to be able tosee great developers in action. Looking at how they code andsolve problems can be a great way to learn how to code well andalso understand details from some specific technologies. Besidesall that, it is also a great way to raise our public profile.

Pair programming

Pair programming is more a social activity than a technicalpractice, enhancing team spirit and bringing developers together.Many developers are afraid to try or think they will feel uncom-fortable when pairing. Many years ago, I used to think like thatbut I realised that I was afraid to expose my own limitations. Ifthat is how we feel, the best advice is to get over it. There is alimit to what we can learn on our own. Of course we can learnwhatever we want since we are all very smart but the problem isthe amount of time that it can take. In addition, we will alwayshave a naive and biased opinion of things if we are always leftto our own judgement.

When pair programming we can learn how to use a new lan-guage, parts of the application to which we have had no previousexposure, a technical practice like Test-Driven Development,a few keyboard shortcuts or even a completely new way toview and solve problems. Pairing can lead to very interestingdiscussions, helping us validate our own ideas. It also can bea very humble experience. Normally, we think of ourselves, asvery good and all other developers are bad. Other developerswrite crap code, not us. When pairing, we have an immediatefeedback on our code and ideas. Our pair validates whateverwe type immediately. Whenever our pair does not understand


what we are doing, or does not agree with a variable name, theuse of an APIs or a design decision, we have an opportunity tostep back and re-evaluate our decision. Instead of thinking thatthe person sitting next to us is stupid (which is rarely the case),we should think that we are probably not as good as we thinkwe are. A good developer is a developer that can write codethat any other developer can understand. When our pairs dontagree or understand what we are doing, we should take this as anopportunity to have a good discussion. Use it to learn somethingnew, open our mind to different approaches and the realisationthat if someone is questioning what we have just done, maybethere is a way to make it better. We should take opportunitieslike that to share what we know, making everyone around usbetter. When teaching, we are forced to structure our thoughts,making us really understand our, quite often half-backed, ideasso we can make someone else understand them.

Pairing with someone from our team or a good friend is great,but pairing with someone that we barely know can be a muchricher experience. Normally teams and friends, after some timeworking and pairing together, develop a common understandingand style of coding. When pairing with people we have neverpaired before, we end up potentially exposing ourselves to verydifferent ways to solve and think about problems. The bestway to find different pairing partners is attending meetings atour local user groups or technical communities. There are alsoan increasing number of developers willing to set up remotepair-programming sessions in whatever we want to work with,sharing their desktops, using tools like Skype and Google+ toremove the distance factor.

We need to keep our minds open to new ideas when pairing.


Sometimes we learn, sometimes we teach and sometimes we doboth.

Socialise

Not only individuals and interactions, but also acommunity of professionals

The vision that software developers are introverted nerds istotally outdated. Finding other developers with whom we canbounce ideas, pair-program and network is almost essentialfor a successful career. A great and easy way to do that isto join your local user groups and technical communities andparticipate in their events. They normally promote free talks,coding activities and social events. Another great aspect ofbeing part of a community is the feeling that we are not alone.User groups and technical communities tend to be extremelyopen and welcoming. We find developers from many differentbackgrounds, working for completely different industries, dif-ferent technologies, languages and processes. Some developersare more experienced than others but there is one thing they allshare: passion. The great thing about passionate people is thatthey are constantly learning and are very happy to share whatthey know.

Being a member of our local user groups or technical communi-ties is a fantastic way to learn and share ideas. I will be talkingmore about technical communities, mainly those focused aroundSoftware Craftsmanship, later in this book.


Deliberate Discovery

I know that I know nothingSocrates

The biggest mistake that we, software professionals, can makeis not accepting that we dont know what we dont know.Not knowing what we do not know is also called second levelignorance. Accepting it is a sign of maturity and one of thefirst steps towards mastery. The vast majority of us have anatural tendency to be positive and optimistic. An example ofthat is how bad we are at estimating tasks. Compared to ouroriginal estimations, the large majority of tasks will take moretime than expected, not less. We need to accept that there isa massive chance for things to go wrong, which means therewill be unforeseen and unpredictable problems. Unfortunatelywe have absolutely no idea when, where, what or how. Theconsequences of us ignoring this fact is that we will be caughtby surprise and will not be able to handle the situation as wellwe would if we knew about it before hand.

There is not a magical way to completely solve this problem butwe can try to minimise it. One way of doing it is to constantlyexpose ourselves to situations where we can learn somethingnewuncovering and learning things about the context ourprojects and we are in. This is very important mainly in the earlydays of a project or before building a major set of new features,when we are most ignorant about what we need to do. Spendingtime trying to identify and minimise our ignorance across all theaxes we can think of can be time extremely well spent. This is


what Dan North calls Deliberate Discovery.

According to Dan North, ignorance is the constant. Imagine wecould do a recent significant project over again. Same people,same requirements, same organisational constraints, same ev-erything but the difference this time is that we would start withall the knowledgewe already have. How longwould it take us thesecond time, all the way through? Now, stop and think about thatyourself. When Dan asks this question, normally the answersaverage between 1/2 and 1/4 and thats where my own answerwould be as well. One of Dans conclusions is that ignorance isthe single greatest impediment to throughput, meaning that if wereduce the level of our ignorance as fast as we can, we can be farmore productive and efficient.

We should always try to create opportunities to ourselves wherewe can learn something we dont know. You may ask, but if Idont know what I dont know, how can I create opportunitiesto learn that? Speaking to random colleagues and asking howthey keep up with the industry. Go to technical communitiesand user group events. Show your code to other people. Ask forhelp even when you think you dont need it. Try to figure outwhich aspects of your current project you and your team havenot explored yet, then start discussions about it or even writea proof of concept. Aiming to remove the ignorance constraintshould always be your priority in order to deliver projects moreefficiently and grow as professionals.

http://twitter.com/tastapodhttp://dannorth.net/2010/08/30/introducing-deliberate-discovery

http://twitter.com/tastapodhttp://dannorth.net/2010/08/30/introducing-deliberate-discoveryhttp://twitter.com/tastapodhttp://dannorth.net/2010/08/30/introducing-deliberate-discovery

Table of ContentsPrefaceAbout This Book

Software CraftsmanshipA better metaphorWhat does Wikipedia say?A more personal definitionThe shortest definition

Beyond definitionsCraft, Trade, Engineering, Science or ArtA bit of historyThe Software Craftsmanship SummitCrossing bordersCraftsman SwapSoftware Craftsmanship Communities

The Software Craftsmanship ManifestoThe ManifestoSoftware Craftsmanship ValuesThe problem with the ma

Software Craftmanship Sample by Sandro Mancuso

Documents

Transcript of Software Craftmanship Sample by Sandro Mancuso