The Telephone Translation Game

Elisabeth Hendrickson brought up the point, that BDUF (Big Design Up-front) is not comparable to the Telephone Game played by children. The more appropriate analogy is language translation, where you get Lost in translation. She describes the usual requirements gathering, writing a system concept, writing a design document, writing code phase to a translation process several languages:

The business person tells a story in BizSpeak to the Business Analyst who interprets it and retells it in BA-Speak (perhaps in terms of “Must,” “Should,” and “May” functional requirements) to the Systems Analyst who retells it in SysSpeak (perhaps UML Use Cases and/or Sequence Diagrams) to the Programmer who must translate it into TechSpeak (maybe State Models, Class Diagrams, and ERDs) and then code. The languages may have some commonalities, but they have a lot of differences too.

Though I was right getting off to bed, I needed to share this. Elisabeth enlightens the reader with a serious of sentence translations into different languages and then back to english ending up with a screwed up sentence. The key point is the fact to get everyone together in a project to share a common language on the software product your trying to build. Eric Evans called this the ubiquitous language and it is a key concept in Gojko Adzic’s book on bridging the communication gap.

What I’d go back and tell myself

Lisa Crispin motivated this morning an entry on What I’d go back and tell myself. Compared to Lisa I would like to get back a few years more towards my time in university that started in 1999 (yes, I’m not that old zealot). At the time around 2001 I took a course called Software practical that was divided in a theoretical leacture and a practical group work to build a system. During the lecture there was eXtreme Programming mentioned as a new technique with a delightning practice called Test-driven development. By that time I did not get the point and it took until 2008 to realize the benefits of test-driven development. Going back to 2001 or even 1999 I would tell myself that I really should read about test-driven development, refactoring, design patterns and unit tests and dive into more topics. Nearly two years from now I started to read on these things and get the ideas from the great books out there. Currently I feel the need to get even with the books, but am really overwhelmed so far from the pile of books that lies in front of me.

Another thing I would like to tell myself going back into the past, is that I will truly make a good start in software testing and development and see the opportunities to improve my work. Going back to 2005 I would tell myself, that I should not waste the time to investigate on PhD positions at the universities, but rather get some real hands-on in the business. Most of practices and techniques I use today I learned when I was out from university and I’m glad to have learned all this stuff.

Roofer Craftsmanship

Today a friend of mine returned his computer that I repaired. While we stood outside and talked a bit about this and that, he told me about his job and his employee. He is a roofer and working in a craft. The interesting thing started when he told me, that he does not expect his employee to be hired for building new houses. This made me a bit sceptic, so I asked for the reason. He told me, that architects from new house projects do tenders for all kind of crafts, likewise for roofers. His boss does not participate in these tenders, because he knows that his estimates will be too expensive for new houses so he will not get involved in the project. Those companies that get involved on the other hand are lead by bosses that do price dumping in order to get the contract. Often these companies have roofers that need work on four new house projects during one week he said. It was really clear to him, that the quality of these roofers’ work suffers from these unrealistic assignments. He used the german word “Pfusch” to describe the level of quality of this work. In one or two years this roof will lead to mildew in the walls and all the like. Since new house projects don’t save money on the roofers but also on the other craftspersons, the result is likely to turn out awkward after some years. For a comparison he said that his company is happy with one roof over a week. He also mentioned, that his boss every now and then tries to do the same – push the people to make their job faster. They then ask the boss what does he expect from their work? Should they use just one instead of the usual five nails for each root tile knowing that their work will be of less quality? This is the point where the boss gets the insight, that it does not make sense to push for work being finished faster.

How does this relate to Software Craftsmanship? Take a step back and read the Manifesto for Software Craftsmanship now. There are four statements in it, similarly to the Agile Manifesto. Let me re-state these and raise my points here.

Not only working software, but also well-crafted software.

My friend, the roofer, knows that it does not make sense to deliver a roof that is working today, but is going to fail in one or two year. That is why he chooses to do his craft – roofing – properly and deliver his best result to the happy customer. Sure, it will be more expensive, but for good. Likewise delivering software that works today, may result in software that does not fulfill the quality needs of tomorrow. James Bach currently has a series on his blog, where he describes the quality creation myth in perfection. (Make sure to read the comments as well.) Quality is not built into our software, it is a time-effective reception of the product we built. This means it may be of good quality today, but might be of bad tomorrow if it fails to realize the new quality standards by then.

Not only responding to change, but also steadily adding value

My friend, the roofer, knows that it does not make sense to deliver a roof that is poured in iron and costs a lot to change its color. Who is going to buy these kind of roofs anyways? Supermarkets with a flat root maybe, but not a usual housekeeper. Likewise in software we must not think of requirements, design, code, tests as being carved in stone as well. We need to steadily deliver something that makes our customers happy. If I want to change my roof today, I can call a roofer and he does just this for me. Surely, this might take some time, according to his open contracts, the progress he is able to make, the wheather, but that roofer should know what I would like to get and that I might change my mind in two or three years. In most software projects I was involved in so far most people didn’t know what they did two hours from now. Without having an impressive set of unit tests they will even not get back into that knowledge quickly anymore.

Not only individuals and interactions, but also a community of professionals

My friend, the roofer, knows that he needs to collaborate with the community of roofers. He pretty much knows that it will pay off to visit a course in Berlin starting from summer to make his journeyman degree together with other community professionals. He knows that there is something he can learn from these other girls and guys, too. Likewise Coding Dojos, conferences and exchange in person or over the internet helps to build that community and exchange thoughts on different techniques. My friend the roofer knows that he has the opportunity to learn something for his whole life. I know this as well.

Not only customer collaboration, but also productive partnerships

My frined, the roofer, knows that by delivering a worthwhile roof today will get his boss into the position that today’s customer recommends his work to other stakeholders. That is why he chooses to push for the best job he can do today, even if this means to stretch the projects deadline. Maybe the recommendations from today’s customer will lead to new contracts for the next ten years. Likewise by producing the best software you can today (for some hints watch Robert Martin’s talk on Craftsmanship and Ethics), you may bring in contracts of tomorrow to your company. This may as well mean that you have to make a more expensive offering in terms of time or effort. But this time and effort pays off.

Skill

There is one more thing the roofer knows, but it is not mentioned in the manifesto explicitly. The roofer knows several techniques how to build a roof. There is one way or the other. He has a skillset of techniques that he can bring into each new project in order to help the customer get the roof they need. That is craft. Likewise a software craftsperson should have a skillset handy for each different project she might be involved in – and even those skills needed in other projects as well. I can’t tell you that you will never need Mock Objects, maybe you will, maybe you won’t. But knowing Mock Objects if you need them, is better than the other way round. This is the condome principle: Better to have one and don’t need it as to need one and don’t have it.

Trade-Offs

While reading the excellent xUnit Test Patterns book I was introduced to the idea that making something less private on a class in order to get a test for it in place may break encapsulation for good. While this pattern ensures that you just have a single instance of a configuration or memory consuming object in your production system, you will have a problem with unit testing it. The xUnit book provides a pattern to make this easy. However, the Substituted Singleton pattern relies on the fact that you don’t define the singleton instance on your original class as private, but rather as protected, so you can override the instance by a subclass where you have influencing methods so you can influence your test behaviour directly. This breaks the encapsulation of the class you wrote for production use, but for good, since you can now test all your users of that singleton class rather than needing to do some special treatments of your environment in order to achieve the same. A similar reasoning can be applied for not using the final modifier on classes. These ones you will not be able to test by then, too. When deciding to do just this, you’re trading off the ability to unit test your code and show that you produced a good quality while doing so and communicating your intents for the next programmer having to deal with your class by breaking encapsulation in your class hierarchy. The first overweighs the second here.

Currently I am faced with a similar situation at work in a different context. We use Perforce for version control at work. This tool is able to indirectly track renamed files not directly – you have to do an integrate to produce a copy with a new name and delete the old file afterwards for that. The current eclipse plugin for Perforce does not cope with this. It just deletes the old file after having created the new file and opened that one for add. By submitting this change you loose the version history and cannot see anymore that the previous name of a class was Foo and is now Bar or that initially you had put up the class in the package foo.bar and now is placed in foo.baz. One of my colleagues realized this and now mandates that we should do a semi-manual refactoring for these kind of operations (rename class, move class). Personally for me the same trade-off as for encapsulation of fields in singletons exists here. Having tool support for doing these refactorings completely automatically is a big win and I can live with the fact that I will not obviously see where the file was coming from in the version history. The class was renamed to hopefully some good reason – i.e. to communicate intent in a better way or to have it placed under a package, where it is reasonable. On a side note all the history I would need should be placed in the unit tests for the classes. This trade-off is fine for me and I don’t see good reasons to get into the semi-automated process of manually integrating a file in the version control system, just to see the complete history of the file. It’s fine if I just see, “Oh I added that file and deleted that one in the first change to that file, seems like a renaming operation.” and follow-up on that file if needed (I don’t read the revision history often – most of the time I don’t have to.)

Mindful readings today

James Bach posted a delighted comment on Michelle Smith’s experiences with new colleagues. Reading through her blog entry, I was delighted myself. Currently I’m hoping to be able to participate in the Rapid Software Testing course during this year as well.

On a side note there was a reference in Michelle’s entry to another interesting point for testers: knowledge sharing. After reading through it, I have to admit that the software testing profession needs more sharing of thoughts. Personally I hope to be able to do my degree of share for our profession with most of the entries here. Unfortunately during day to day work I experience quite the opposite attitude – even now during critical times.

Another interesting blog article from today is Matt Heusser’s call for The History of Ideas in Software Testing. The idea seems to be great to me. Unfortunately I have just been three years involved in the business and still need to cover up on most of the things so that I could not contribute worthwhile references so far.

Testing focus of Software Craftsmanship – Principles II

In the last few weeks I have not taken the time to follow-up on the series I started some weeks ago. In the meantime Lisa Crispin had an entry on ten principles for Agile testers as described by Jeff Langr and Tim Ottinger. Since I took some of the principles from Lisa and Janet, you will find these as well on my list as well – though I recommend buying the book anyways.

  • Respond to Change
  • Responding to change is critical in most software businesses. Customer requirements keep changing. Therefore the most valueable needs to be able to cope with that change as well. As a tester it is therefore counter-productive to act as a gatekepper with a conservative view towards change. Bach, Kaner and Pettichord were the first I read this about, though the underlying thinking clearly is not new. As testers we need to be able to respond to changes demanded be the business as well as changes demanded by technical constraints such as the programming language of the system under test or test automation tools. Insights from Refactoring and Design Principles such as the SOLID principles from Robert Martin are tools of knowledge that can help to adapt tests to the chaning business. As pointed out by Robert Martin

    Knowledge of the principles and patterns gives you the justification to decide when and where to apply them. If you don’t know them, your decisions are much more arbitrary.

    This applies to developers as well as to software testers.

  • Self-Organize
  • Without self-organization testing becomes a tedious task. If your work is organized from someone else, your testing tasks become a job of a assembly-line worker and you could be replaced by the next student looking for a job. This might seem a hard statement and I’m exaggerating to some degree, but if a tester does not organize herself, then why not replace her with a cheaper student? As highly educated professionals we have to take care to do a good job and defend our position on what is to be done in order to work on the project at hand. This may mean to write a big test plan up-front, this may mean to find the proper amount of automated and exploratory tests or this may mean to bring together business people, developers and testers in order to improve communications. Of course our decisions are sometimes wrong on these items. In that case we need to be human enough to learn from our failures in this case in order to improve.

    Probably the most common violence of self-organization lies in the fact, that most testers are waiting for something to be delivered to them. Even ten years after defining test-driven development and the Agile movement this is the case. Robert Martin raised the point of Never be blocked during his talk on Craftsmanship and Ethics from the JAOO Conference. The need to wait for something to be delivered means that you’re blocked. Prevent these situations by finding ways to work together with your developer. Maybe you will find that there is a vast amount of unit tests for your particular business rule and these are regularly run. Maybe you can improve the code before it gets to you. You need self-organization to see these opportunities and decide whether to take the next story or improve the software at the instance it is written.

  • Focus on People
  • Regularly testers on traditional style projects complain about getting source code just thrown over the wall. While agile methodologies focus on the whole team participating in testing, the more general principle behind this is the focus on people. Testers not getting out of their cubicles in order to talk to developers, management and stakeholders cannot expect to get involved early in the development cycle. Did you ever try to talk to your lead designer before firing that blocking bug into the bug tracking system? When did you ask your customer about that edge case left out during specification gathering the last time? By letting the people around you on the project decide what to do in the situation at hand, you might be invited to the specifcation workshop the next time. Matt Heusser described this moment as How to be a first-class citizen as tester. Just when you have the intuition that something is broken and can show this to your stakeholders, you’re going to get invited to the elephants’ meetings afterwards – maybe. Focussing on people is the more general principle behind this and may get you on the road to the first-class citizen in your company.

  • Enjoy
  • Based on my previous work experiences – not just in the software world – enjoyment matters most. An unhappy tester that just gets flooded by over-the-wall-thrown code is unlikely to deliver back value to the project. If the testers are filled with pride in their work, they will even enjoy their work and become an essential part of the project team. Some weeks ago I took a voluntary session with Michael Bolton. Michael had selected an exercise from his courses on Rapid Software Testing. We had timeframed our session previously to one hour, but ended up at 1.5 to 2 hours. We overdraw the session, but I did not feel to comply about it. I experienced so much enjoyment during the session, that I wanted to share this experience with my peers immediately. One week later I did. And they felt the same. While enjoyment cannot be mandated by a manager or corporation lead, if you’re in the situation to enjoy your work, your giving it a better care – which improves your enjoyment as well. Enjoyment prevents us from taken the next job opportunity, from becoming a developer, etc. Taking in the joy into our work helps to have pride in it. You shouldn’t live without it.

  • Testing moves the project forward
  • Some months ago Cem Kaner wrote a rather long chain of replies on the Software Testing group on an article by Lisa Crispin and Janet Gregory that reminded me on this principle in Lessons Learned in Software Testing. One of the key points that Agile methodologies showed us is that tests really drive the development effort forward.

    Test-driven development is more considered a design technique as a testing technique. Similarly Gojko Adzic redefined Agile Acceptance Tests as Executable Requirements in his book Bridging the Communication Gap. Both practices have somehow their roots back about 50 years in time, as I got to know by a blog entry from Jerry Weinberg. They all three have in common that these techniques have been motivated initially by testing needs. These are examples where testing moved the software development process forward and the same holds for each project as well.

  • Testing is not a phase
  • In order to take proper effect, testing needs to be a continuous action. When testing is handled in a phase after the fact – after the software has been built- then all the made up assumptions during the earlier phases – like requirements, concept, design and code – sum up into one single point: the tester behind the wall. Have you ever wondered, how come you’re testers need so much more time than you to code? Fred Brooks wrote in The Mythical Man-Month that just a tiny piece of the time spent in a project is taking for actually writing the code. Requirements, concepts and designs give developers a good starting point on the business terms in the project. In order for testers to do their job well they also need to have this knowledge right from the start. By just giving them the code and the 500 pages of documentation, you’re not only treatening them as lessers, but also making their time spent on projects a hard deal.

    On the other hand quality in software is not built, as James Bach lately pointed out. All practices during the development of the software need to ensure that the quality in it is kept alive. Testers and testing in general cannot bring back a dead body of quality in your product, if it’s decomposing there for months already.

  • Everybody tests not just the designated testers
  • After the last principle this should be obvious. The whole team is responsible for having the product tested. Every code review, Pair Programming session, Iteration Demo, Specification Workshop etc. enables the whole team to participate in testing the product. Since everyone on a deveopment knows a tiny of the software, getting everything together in form of an executable specification of the product enables the team to deliver business value from the start. If everybody is part of the testing that’s happening, the Broken Windows Effect is minimised and bugs don’t start to pile up.

  • Reduce feedback latency
  • Feedback is a core value in nearly all Agile methodlogies. Recently Robert Martin gave a key talk on Craftsmanship and Ethics where he pointed this out while referring to unit tests and code coverage.

    Have ever looked on a function you implemented two hours ago and thought: “Oh my god, what’s this doing?”

    Feedback latency is essential for testing. Just quick feedback on a broken build, damaged customer value and technical debt gives you the opportunity to learn from it. If two weeks of development passed by, you’re most likely to have lost the red line in the code. This is why feedback needs to provided immediately.

  • Tests represent expectations
  • When dealing with Specification Workshops or in Acceptance Test-driven development the team defines together with the customer representative how the system should behave after the agreed on functionality is implemented. Test frameworks as FitNesse or Concordion shorten the gap between these examples or expectations and the tests used in order to drive your development forward. By being able to directly use the output from your requirements, you’re able to product the right code. Similarly unit tests focus more on producing the code in the right manner. Therefore they reflect more the design expectation in your development efforts. It should be obvious that you cannot live without one or the other.

  • Tested is part of “Done”
  • A feature or story is just defined as being done, when it’s really tested. The feature is not production-ready when the developer has finished the coding for it. Instead it is finished when everything is in place to get the tests passing, the acceptance from the customer in the iteration demo and thereby the production ready configuration of the parts. Everything else is scaffolding and should be avoided completely. Particularly does scaffolding in the software business lead to higher maintenance costs for features that had not brought in any money. Just tested, production-ready software enables your company to earn money from your work.

    Considering different your daily work, the motivation for team members will also change. Instead of sub-optimizing towards “but I’m finished” mentality, definining “Done” as “Tested” enables developers to look over their wall and see if the brick they just throw did any hurt. By moving the measurement on level up from “coded” to “tested”, there is call for all team members to focus on just this bit rather than sub-optimizing just their building lot. The project and the team is not finished with a particular piece of functionality, if the customer cannot use it – period. This is reflected in this principle.

    PerforceCmSystem for FitNesse

    Today I finally set up a project page for the PerforceCmSystem that I worked out initially for the 20090214 release of FitNesse. The implementation is simple and just enables your fitnesse pages for version with FitNesse by opening new pages for add, opening already submitted pages for edit, and deleting removed pages in the default changelist. Anyways you will still have to take care of the submission process by yourself when doing so, so don’t consider this to be the silver bullet. After updating to FitNesse 20090321 which was published yesterday by Robert C. Martin I decided to add downloads compiled for Java 1.5 and above to the project page. Let me know of any issues you’re facing.

    1500 people fighting crappy code

    Micah Martin just gave a personal answer to an upcoming article on InfoQ on the Software Craftsmanship Manifesto, that was put into public this weekend.

    2) How will it help solve the problems of crap code?

    As of today, there are over 1500 signatures on the Manifesto. 1500
    people are fighting against “crap code”. Those who have been fighting
    “crap code” now know that they are not alone in their fight. Those
    who write “crap code” now know that there are 1500 people fighting
    against them.

    The Manifesto is a gentle push away from “crap code” and toward
    craftsmanship.

    Personally I would like to make some posters with this statement printed on it and hang them out in public at work. Maybe someone can come up with an information radiator, which is updating the number of “crap code fighters” as anyone new signs it.

    Software Craftsmanship Manifesto

    Doug Bradbury and Paul Hagel compiled together the Software Craftsmanshup Manifesto. The Manifesto is based on an initial summit in Libertyville in December 2008. After that summit, the output was discussed over the last two months on the Software Craftsmanship Googlegroup resulting in a distinguishing list of values similar to the Agile Manifesto.

    I had to immediately sign this manifesto, since I couldn’t agree more to it. Over the past one to two years I have seen crappy software built under higher management constraints lacking basic quality. Taking Jerry Weinberg’s quote “Quality is value to some person.”, I don’t see much value in most of the software I have to deal with on a daily basis. James Bach seems to have a similar view on the things. That caused him start a series on the death of quality this week; just 24 hours later he explored together with Michael Bolton a software project, which claims to deploy 50 times a day resulting in poorly received quality – at least for James and Michael.

    Currently I’m hoping that craftsmanship thinking can bring the software development business back on track. Personally I would like to write code to be proud of and don’t have a bad feeling about that one class, where I screwed up. As a software craftsman I appreciate the work of others around the globe in the field and I’m very glad to exchange thoughts on their work and my work at conferences or via online tools such as instant messaging or desktop sharing. Just this week I had the opportunity to exchange some thoughts with Michael Bolton and I experienced a very nice contact in it. Michael had the ability to make me think on many things, that I have already read about – 2 years ago – but forgot to include into my daily work life so far. Just one week ago I had the other opportunity to meet Gojko Adzic at the Software Craftsmanship Conference in London. One year ago I started to give Lisa Crispin and Janet Gregory feedback on their book on Agile Testing. I’m sure I could perpetuate this list even more, but personally I would like to stick to the most meaningful contacts from the last year for now.

    Maybe poor received quality has become a linear feature in our software systems. Maybe most of the people out there think this is ok. This is where I personally heavily disagree. Being a perfectionist to some degree I would like to see software that delights myself, where I say “why hasn’t this product been developed in this case long ago?”. From my point of view this distinguishes mass-market software from well-crafted software.