London Software Craftsmanship community - first meeting

There was a great turnout for the first meeting of the London Software Craftsmanship community, close to a full house at our gratious hosts SkillsMatter.  The following is a summary of the first meeting talk and discussions.

The founders of the LSCc David and Sandro, laid out their ideas about software craftsmanship for the community to chew over and discuss - which members did with great vigour especially towards the end of the evening.

David and Sandro set the tone by annoncing that they are asprining software craftsmen and started the community to bring together lots of ideas share experiences as to what that means.

Some scene setting by David, discussing how programmers are often used just like typists, when really development is an artistic process.  Terms like software factory are not what the industry is about and focused on the wrong things.

Warm-up
There was a bit of exercise to warm the audience up, getting us all to stand up to figure out just what sort of audience was attracted to this event.  It was good to see a mixture of developers, testers, coaches, analysts and even a CEO.  There was a big contingent of Java developers and quite a few .Net devs even thought there was the LDNUG event the same time.  It was good to see developers from the python, perl, android and even Erlang space too.  There was a nice mix of age groups, quite a few in the over 30 camp but also university students and recent grads.

The talk proper started with an example of how software engineering practices were introduded at NASA, allowing them to  deliver 42,000 lines of code with only 17 bugs - the only problem being this cost them $35 Million per year and projects were always delivered late.

Raising the agile model, this was portraied as a very productive time for those teams that really understood the principles and practices that agile estolled.  Software craftsmanship was not portraied as a replacement for agile, but perhaps as a way to help us get back to thinking about the core principles and practices of agile that may be forgotton as agile spreads and transforms into "wagile".

The good enough approach is not always good enough and it was felt that many agile projects are now, steadily and iteratively producing mediocre software.

The idea
So, is Software craftsmanship the new shiny toy on the shelf that we all want to play with or does it have something meaningful to say?

David introduced a quote by Robert C Martin:

"The original torch of the agile message has changd hands to the software craftsmanship movement"

and refered to the wikipedia entry on Software Craftsmanship.

Delving deeper it was not portraid not as a certification process, a training course, a book, a tool or specific technique.  Simply it is something that you are, the way you approach your work, treating software development as an art, a craft, something you care about.

The Manifesto
The desire to raise the bar of professional software development by practicing it well and heling others learn the craft was expressed in the creation of the manifesto for software crafstmanship:

• Not only working software, but also well-crafted software  -- it should be as easy / enjoyable to work on an old project as a greenfiled one
• Not only responding to change, but also steadily adding value - extending the life of your projects
• Not only individuals and interactions, but also a community of professionals - helping each other develop our craft
• Not only customer collaboration, but also a productive partnerships - we need to help our clients / employers to value better understanding and better solutions

So what does it take to craft software?
Offered up were the concepts of creativity, judgement, theory and practical skill.  Understanding that continuous improvement was seen as the most highly valueable goal, as there are always more things to learn.

One of the most common ways to practice the craft was to undertake deliberate practice - via coding and architectural kata to practice the are, coding dojo to learn language design, and code retreats to learn good design via test first development.

The Journey
Software craftsmanship talks about a journey from apprentice, to journeymen and then master.  The apprentice experiences more learning than teaching and is mentored closely by a master.  The journeyman has responsibility to take on projects unsupervised and works for many different masters to broaden the range of their experiences.  It was commented that the journeyman was best placed to move the industry forward as they have a broader view than a master.

Sandro talked about how you dont have a control over becoming a master - it is driven by the community who look to certain individuals that are perseved as being highly experienced in a particular area.

These labels whislt interesting to talk about how you travel along your journey are not in themselves an important aspect of software craftsmanship.

In summary
The great conversations continued in the "SkillsMatter" pub, The Slaughtered Lamb and there was a lot of merry making going on there after the event.

For myself, a simple way of thinking about all these concepts software craftsmanship is to consider being "responsible", taking actions that are the most responsible thing you could do at the time within the constrains put upon you whilst still delivering value.

Understanding can be difficult if there is confrontation!

When trying to share some knowledge or raise issues, I try to lead the audience (audience being an individual, team or community) on a thought trail rather than pointing out issues directly or just imparting the answer.  By laying out a path of thinking, the audience is more likely to engage with the concepts or information you are imparting and become involved in path to the answer.  Once on the path, the audience is more likely to accept the outcome.

Okay, so how do you start a thought trail, it sounds like a long, drawn out, boring process!
Start with the problem statement !!!  rather than a question ???

Using the Socratic method of understanding is beneficial to the person who is playing the role of Socraties as they are able to drill down in to the real meaning and understanding of another person.  However, asking a hard question (Why often being a hard question at times - if you don't know why you do something) and making people feel they should have the answers at their finger tips is not as conducive to knowledge sharing or collaborative problem solving

Empathise with the audience that have the problem, make that audience feel you are or have been in their situation, this will make them feel warmer and more receptive to what you have to say.

Example:
Socratic Question: Why are you talking to a reporting copy of a 3rd party database that is a day old rather than talking to the application in real time?

Empathy statement: I am concern that we are doing a lot of work to integrate with this application and the information may be out of date.  If the schema changes then we may have a broken system and have to carry out a lot of rework under pressure from our angry customers.  If we were able to talk to the application directly and ask it questions, perhaps that would require less setting up and would be less likely to change.

The Socratic question, whilst perfectly valid, puts potential conflict in the way of the problem space.  You can often make the person you put the question to feel that they are to blame or have made a stupid mistake.  If the person is made to feel uncomfortable or in the wrong, then they are less likely to work with you or listen to your advice to resolve the problem.

Using the empathy statement, you have asked the same question, but have asked the person to go on a journey with you to understand concerns of the problem raised and evaluate whether a different approach has merit.  The person is encouraged to feel part of the solution, rather than being the cause of the problem.

In writing this article I started to break the premise of the piece by using a title that was a Sochratic method style question: Empathy over Sochratic method?

Instead, I went for the title: Understanding can be difficult if there is confrontation!

I wrote this article after reading the preface of The Goal by Eliyahu M. Goldratt and Jeff Cox.  The preface is describing the style of the book which is in the form of a story.  The preface states that this has been an effective book style to get across the many issues coveres in an engaging way.