Craftsman or Professional?

A guide for craftsmen

Jason Gorman wants “…a guide book on Applied (or Interpreted) Software Craftsmanship“.

Could the “Software Engineering Code of Ethics and Professional Practice” be a place to start?

Are you a craftsman (or -woman, I suppose)?

Are you a professional?

Summary of the code

The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.

8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Copyright (c) 1999 by the Association for Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers, Inc.

Read the full version.

Book Club

Starting up a book reading group

J., the manager of the Financial systems IT department, came to me for advice. He wanted to expand his developers’ knowledge and responsibilities. He wanted them to grow beyond pure development: to get more involved in architecture and analysis, interact with customers… We looked at several options and finally decided to start up a book reading group.

In a book reading group, a number of people get together to read and discuss a chosen book. To set up a book reading group:

  • Invite participants. Participation isn’t mandatory.
  • Select a book that interests the participants.
  • Get enough copies of the book, so that everyone can choose when to read.
  • Define a suitable reading pace. For example one chapter per week. Keep the iterations short.
  • Agree on a fixed meeting schedule, time and place to discuss the book. The discussion is often scheduled during a lunch break, with lunch provided by the company.
  • Moderate the discussion and record the main insights, so that there’s an output and those who miss a session can catch up.

The quiet team

There was something unusual about this team. They were so… quiet. You probably don’t want your accounting, invoicing and ERP systems maintained by a bunch of party animals, but still. These developers rarely talked to each other, they all worked individually on their own part of the systems. I was a bit worried: would they come to the discussion meetings? Would they say something?

What would be a useful book for this team? They all had different backgrounds, worked on different applications and used different technologies. I proposed we should start with something that would be useful as a basis for further study. We chose “Quality Management I: Systems Thinking” by Gerald Weinberg. I’ve found Systems Thinking to be a useful tool to make sense of a lot of situations, but would the team find it interesting? Would a book about “management” be useful for developers? The manager and I decided it was worth the risk.

We’ve noticed that some people will find or create the time to read books to learn more, but they are the exception rather than the rule. Many people are so busy at work that they don’t have the time to read books. Reading a book isn’t “work”. And the principle of “sustainable pace” surely means you shouldn’t be spending time reading work-related stuff outside of work.

The reading group has a number of advantages:

  • Reading becomes part of “work”.
  • Peer-pressure and the short timeboxes ensure that participants create the time to read one chapter every week.
  • The discussion sessions ensure that participants read more attentively and hear how others interpret the material.
  • The discussion regularly leads to ideas for improvement actions or people getting together to try out some new idea.
  • Reading the book together improves team cohesion and (cross-)team communication. Even if participants work on different applications or work in different teams, they’re doing something together and realise that they face the same issues.
  • A reading group reveals strengths, weaknesses and skills in individuals you wouldn’t usually notice about one another working together day-to-day. This discovery could lead to increased appreciation among team members which, in turn, leads to increased respect.

Group learning

The first couple of sessions required a lot of facilitation to get participants to speak up and give their opinion. The participants didn’t see the relevance of systems thinking. And why were we reading a book about management? They weren’t managers. They were developers.

Luckily, they kept coming to the book group, they didn’t give up. Gradually, they started to speak up more; discussions started; they debated different viewpoints. They started to see things in their environment, things that had always been there. But now they saw the world with different eyes. They started to see the connections between things. They started to understand why things happened as they did. They started to realise how they could influence their environment. They started to generate ideas to improve the way they worked. The group required less and less facilitation: two participants emerged as leaders, they kept things going. I didn’t have to say anything; I just acted as their scribe. The team was no longer quiet; they were full of energy and ideas.

When starting up a reading group:

  • Ensure that there’s enough support and encouragement from the coach, a manager or some team members to get the group going. The first two chapters of a book are often not very exciting; the group needs to get to know each other and the format.
  • Small signs of company support like paying for the books, providing a place to meet and buying lunch shows participants that they and their growth are taken seriously.
  • Provide facilitation to get the discussion going and to keep the meeting on track. As the group gets more experience and self-organises, they will require less facilitation.
  • Take notes and publish them so that those who weren’t present can see the outcome. Publishing an output raises the importance of the meeting.
  • Ensure that the book is relevant to the work of the team. Let the team describe what they want to learn. The coach should have enough experience to suggest books that fulfil the requirements of the team.
  • As with iterations, a regular pace with short iterations is crucial. We recommend weekly sessions, to discuss one or two chapters.
  • Ensure you always meet in the same room at the same time. Don’t reschedule the book group meetings because someone can’t attend. They can always catch up.
  • In a larger or more heterogeneous team you can create two groups who read a different book. Discussing the two books together gives everyone some insight into both books. Maybe the participants will find interesting links or contradictions between both books.
  • Try to find books that contain questions or exercises for the reader. Participants must answer one question or perform one exercise per chapter. The group facilitator can set up questions or exercises for the group.
  • If participants are uncomfortable during discussions, the facilitator can use techniques like a clustering exercise to elicit everyone’s input.
  • The discussion will often result in ideas for improvement and action. Handle these like you would at a retrospective: prioritise them by value and include them as part of the team’s delivery iteration.

Mini XP Day Benelux 2009

The dangers of success

XP Days Benelux 2008 was a success, as evidenced by all the smiling people in the conference pictures and the positive feedback about the conference and the sessions.

But…

  • Many people couldn’t participate because the conference was sold out. We cap the number of participants to (on average) 30 per track, so that the sessions can be interactive with participation from all attendees.
  • Many participants were frustrated because choosing one session meant not being able to attend a session in the four other tracks.
  • Good sessions improve when they’re run again as the presenters incorporate feedback. We do have a collaborative session proposal refinement system, but after the XP Days it’s done.
  • How can we reach more people? If we grow the conference and allow more people we will either dilute the experience (more participants per track) or need to add more tracks. With more participants, the organisation becomes more complex. There is a greater risk that the participants will split in groups of people with similar interests and backgrounds so that there’s less exchange of ideas.
  • The organisation of XP Days is done by volunteers. We all have a limited amount of time we can invest.

How can we solve these problems and make the XP Days even better?

Mini XP Day – XP Days greatest hits

Mini XP Day is a one day event where we rerun eight of the most liked sessions of the previous year. It’s a second chance to participate in these sessions.

There are only two tracks, so participation is limited to 60. Such a small event requires less effort and time than a full XP Day conference. For example, there’s no session improvement and selection process to go through.

The preliminary program (two sessions have not yet been confirmed) is now online.

So, here’s you chance to go to four great XP Days sessions.

Don’t wait too long to take it.


Pictures by Xavier Quesada

XP Day Switzerland

Another XP Day!

XP Days branches out: our French-speaking Swiss friends organise the first XP Day Switzerland in Geneva on Monday March 30th, 2009.

The conference is a good opportunity for me to return to Geneva and see some of the local Agilists again. I’ve got great memories of the conference center, where I presented the Toyota Way and the participants discussed Toyota, Lean and Agile into the night. I’m looking forward to go for a run along the lake.

The conference program has been published at http://www.xpday.ch. The detailed descriptions aren’t available yet, but judging from the subjects and the speakers, this looks to be another fun and interesting XP Day.

Another new session!

One of the proposals Portia and I sent in got accepted. For the occasion, we’ve developed a new session: “Les Cinq premiers pas pour devenir vraiment agile”. In this interactive presentation, the audience gets to try out 5 “tools” we use when coaching teams that are new to agile. They can immediately put these tools into practice during the conference day.

I’m really looking forward to this session. If it all works out, this will be both fun and useful. The session is scheduled at the start of the conference because it also serves as an ice-breaker. We might be able to reuse parts of this session for other occasions. Like the one that will be announced soon…

More XP Days news

Watch this space for more exciting XP Day news soon…

Beyond Jidoka – Poka-Yoke

Do you want to improve your productivity?

There’s a very simple way to improve productivity.

How much time do you spend on “bugs”? Finding them, analysing them, fixing them and making sure they don’t reappear. Not to forget the time spent writing the bug.

Imagine how much time you could save if you stopped writing bugs.

How do you write bug-free software? It’s simple.

Jidoka is not enough

Great, you’ve implemented Jidoka. Your systems and people find issues quickly. Your team responds quickly to resolve any issue raised. You even improve your tests whenever another issue slips through.

You’re well on your way to deliver quality quickly. But there’s something missing.

Poka-Yoke

Poka Yoke is the practice of “mistake-proofing” work. It’s another principle from the Toyota Production System. Poka-Yoke mechanisms ensure that the user or operator can’t make a mistake. For example a plug that can only be inserted correctly (like the 3 pin UK plug) or can be inserted in two ways that are both correct (like a 2 pin plug).

Poka Yoke is not Baka-Yoke or “fool-proofing”. The goal is not to prevent idiots from doing the wrong thing, but to make intelligent people do the right thing.

Poka-Yoke software

We can Poka-Yoke software if we really think about it.

In one case, a web application didn’t work because of an incorrect configuration parameter. Two tools each required a configuration setting. The two settings had to correspond. One configuration, created by the developers, contained ‘G004’. The other configuration, maintained by the sysadmin, contained ‘GOO4’. Can you spot the mistake?

Once we found it, the issue was easy to fix. How could we avoid it? Some thinking and experimenting showed that there was a way we could reduce the configuration to one setting, even with the existing tools. This type of error couldn’t happen again.

Thank you for reporting this error. Finding and resolving issues is a great trigger to add some Poka-Yoke.

It doesn’t have to stop here. Why wasn’t the mistake found sooner? Because this feature was only fully tested in the acceptance environment and the configuration error happened only in the production environment. Why wasn’t it tested in production? Because testing that part of the application could show confidential customer information. Next time, we’ll get someone who’s allowed to see the confidential information to test that part of the application in production. Poka-Yoke the software is the first step. Poka-Yoke the software process is the next step.

I had finished implementing this class. I just needed to add a comment to explain how to use the class. First, you had to call the methods A, B or C. Then, you could call methods X, Y or Z.

This class was very error-prone. Why not write a class with methods A, B and C? These methods return an object of a class that implements X, Y and Z. You can’t call the methods in the wrong order.

If I feel the urge to document, I stop and think. Isn’t there a way I could simplify? Isn’t there a way to change the system so that errors are impossible? The pay-off is clear: less time to document, more time to code.

Poka-Yoke is an ongoing process. It isn’t done until the system is so easy to use it doesn’t require a manual or training. It isn’t done until all testers have become specifiers instead of verifiers.

Doesn’t this take a lot of time?

Yes it does.

But imagine you only had half the issues you have now. How much time would you save? Now invest that time in finding root causes and making your work Poka-Yoke.

It’s simple. But not easy.