ObjectiveView - Nagafixusers.nagafix.co.uk/~mark/ovmag/OV11.pdf · objectiveview – ovmag.com –...

of 20

ObjectiveView ovmag.com

the technical magazine for serious software developers

Home - Paul Christopher Flynn

IN THIS ISSUE:

• Pete McBreen – Understanding Software Craftsmanship

• Jason Gorman - Peer Lead Learning and Software Craftsmanship

• Matt Stephens and Doug Rosenberg – Design Driven Testing

• Rachel Davies – Understanding the Role of an Agile Couch

• Kevlin Henney – 97 Things Every Programmer Should Know

of 20

ObjectiveView

CONTACTS

Editor

Mark Collins-Cope [email protected] http://markcollinscope.info

Editorial Board Scott Ambler [email protected] http:///ScottAmbler.com

Kevlin Henney [email protected] http://curbralan.com/

Free subscription

Notification of release by email – [email protected] (with subject: subscribe ov)

Circulation/Sponsorship Enquiries [email protected]

Authors may be contacted through the editor. All questions or

messages will be passed on.

Let us know what you think! Just email us.

CONTENTS – ISSUE 11 Understanding Software Craftsmanship 4 Peer Lead Learning and SW Craftmanship

7

Design Driven Testing 13 Understanding Agile Coaching 15 97 Things Every Programmer Should Know

18

Design For Test 20

What is OV? ObjectiveView was first published in the late 1990s, and issues have been released periodically since. It is free of charge, in the spirit of Open Source. ObjectiveView’s “mission” is to:

• Positivity challenge – both its readership and the status quo in software development.

• Assist its readers by providing high quality articles on relevant technologies, methodologies and principles related to software development.

• Stimulate discussion by exploring issues that some might like to ignore.

• Promote professionalism in software development.

• Increase the esteem in which software developers are held in the wider world.

Distribute ObjectiveView

It’s easy. You link to ObjectiveView using our linkgif, and your logo will appear on all copies of this magazine. Email

[email protected]

objectiveview – ovmag.com – for back issues

of 20

Back Issues

ObjectiveView Issue #10 – Databases/Automated Testing

• Kent Beck Interview

• C# 2.0 & 3.0 Overview

• Refactoring Databases

• OODBMS Revisited

• How to Work with Legacy Code

• Grady Booch on SOA

• Kevlin Henney - Why the Waterfall Fails

• Matt Stephens - Ruby - I Love You (Not) Ed

• Yourdon - Structured Analysis - A Retrospective

• TDD - Treating Tests as Code

• EA's Model/Code Sync Features ObjectiveView Issue #9 - Newer Technologies Focus

• Alex Ruiz on AspectJ

• Richard Vaughan on AJAX

• Amy Hoy introduces Ruby

• Obie Fernandez - Ruby on Rails

• Rebecca Wirfs-Brock - Specs are Bad!

• Kevlin Henney - Abstraction - Down on the Upside

• Scott Ambler - Glacial Development :-)!

• Ken Pugh - Prefactor and be Agile

ObjectiveView Issue #8 - Agile Development Special

• Kent Tong on Turning Comments into Code

• Elfreide Dustin on Unit Testing

• Tim Mackinnon on Agile Project Retrospectives

• Scott Ambler with the latest update on Agile Model Driven Development

• Doug Rosenberg and Matt Stephens on Combining UML with TDD

ObjectiveView Issue #7 - Focus on .NET

• Microsoft C# author Jon Jagger overviews C#.NET

• Paul Hatcher takes a look at VB.NET

• Richard Vaughan on Managed C++ under .NET

• Interview with author Doug Rosenberg and Matt Stephens on their forthcoming book: XP Refactored.

ObjectiveView Issue #6 - Component Development

• John Daniels & John Cheesman (Authors: UML Components) on UML Components

• Paul Allen (Author: Realizing e-Business With Components) on EBiz Components

• Mark Collins-Cope & Hubert Matthews on Layered Architecture

• Philip Eskelin (Author: Component Design Patterns: A Pattern Language for Component Based Development),with Kyle Brown & Nat Pryce on Component Distribution Patterns

ObjectiveView Issue #5 – Focus on Use Cases

• Interview with Ivar Jacobson

• Clemens Syperski (Author: Component Software) on Components vs. Objects

• Ralph Johnson (Author: Design Patterns) on Dynamic Object Model Architectures

• Keiron McCammon on e-Business Architectures

• Doug Rosenberg (Author: Use Case Driven Modeling with UML) and Kendall Scott (Co-author: UML Distilled) with "Goldilocks and the Three Software Processes"

ObjectiveView Issue #4 – Focus on XML

• Richard Vaughan with an Introduction to XML for Developers

• Author Jason Garbis on Designing Distributed Object Applications

• Author Jan Bosch on Software Product Lines and Architectures

• Why is UML topsy turvy? by Hubert Matthews and Mark Collins-Cope

• Author Brian Hendersen-Sellers describes the OPEN Process

• In-depth technical interview with author Robert C. Martin on eXtreme Programming

ObjectiveView Issue #3 – Focus on XP

• Yonat Sharon summarises Kent Beck's Extreme Programming Process...

• Authors Kendal Scott and Doug Rosenberg put the counter-case to Extreme Programming...

• Paul Crerand of BEA with a detailed technical article on M3 - their Object Transaction Monitor

• Brent Carlson of IBM discusses the use of Design Patterns in SanFransiso

• Author Robert C. Martin with An Introduction to UML Use Cases...

ObjectiveView Issue #2

• Author Thomas Mowbray gives an Introduction to CORBA.

• Author Robert C. Martin on the Open-Closed principle of OO design.

• Anne Thomas (Patricia Seybold Group) on Noblenet Nouveau - ORB/COM/RPC interoperability tool.

• Keiran McCannon of Versant with an in depth article on the case for the OODBMS (vs. RDBMS)

ObjectiveView Issue #1

• Structuring Large OO Projects - Avoiding the Pitfalls

• Object Management Group Analysis by the UK's OMG Representative

• Object Oriented Design Tips

for back issues visit OVMAG.COM


of 20

Understanding Software Craftsmanship

Software Engineering has manifestly failed to improve our ability to deliver quality software says Pete McBreen, author of

Software Craftsmanship. After 40 years of trying to force software development to fit into the straightjacket of software engineering, the time has come to acknowledge that the experiment has failed and we need a new idea…

Understanding where we are In the era of software engineering, hardware was exceedingly expensive and software developers were rare. As a result we had projects where the hardware costs dominated the entire budget, and as often as not, many of the people on the project had little experience in software development. Back in that era, a team lead might have a year or two's more experience than the beginners on the team, and a part of every project was making sure that the developers were adequately trained in the technology. Now the situation is completely different. For most purposes, hardware for the development team is essentially free. Even when it comes to the deployment environment, the cost of the hardware is miniscule compared to the overall costs of the project. True there are some massive scale projects out there where the hardware costs are still significant, but these are few and far between. We also have an abundance of software developers, indeed the problem these days is one of filtering through the candidates. Lots of people have software development experience, so the challenge these days is one of picking suitably qualified candidates. True we still have the problem of getting people who are deeply familiar with the technology that will be used on the project, but we are mainly choosing between people who have differing levels of experience.

People costs now dominate software budgets The obvious outcome of drastically cheaper hardware is that now, people costs dominate software project budgets. These costs probably crossed over back in the era of the mini-computer, but now it is obvious to everyone, that for any project, the limiting factor is the people. The software engineering mindset "solution" to this problem has been to try to reduce the cost of the people through:

- relocating to cheaper areas, - outsourcing the work to other companies, - offshoring the work to cheaper countries. All of these strategies are self limiting. Yes, you can cut costs in the short term, but the problem remains that the rate limiting resource in software projects is now software development talent. The mechanical mindset of software engineering has tried to apply the lessons of manufacturing industry - remember the software factory idea - but these have all failed. We now have lots of different niche specializations in software development, but the result has been more failed projects and less satisfied users.

Understanding Craftsmanship Craftsmanship can be thought of as a historical response to the abundance of partial ability. How does a society arrange for the improvement of skills and abilities in a field of endeavor? The main answer that all societies have come up with is that of a "community of practice" where practitioners can share information and where beginners can go to get trained as practitioners. Craftsmanship traditionally uses an apprenticeship model for training beginners, not because the academic model does not work, but because there is a certain amount of hands-on, practical feel that has to be developed. Schooling is useful for learning the detailed information, but it is the situated practice that makes the difference with the traditional crafts. Modern apprenticeships are now a mixture of schooling and hands-on supervised work. This is true of the traditional crafts like blacksmithing and farriers, and the more modern crafts like toolsmiths. Software development is becoming more like a traditional craft every day. There are lots of people who have fairly detailed knowledge about software development, but the fact remains that academic knowledge of software development is insufficient. All beginners in the field of software development knows this, because it is very hard to get hired without experience. Most software jobs require a minimum amount of experience before the applicant will even be considered for an interview let alone hired.


of 20

Although universities and colleges have tried to address the lack of experience with "work terms" and "capstone projects", these have not been seen as an adequate replacement by industry. The problem is that without working as part of a larger team, it is hard to get a good feel for what it takes to deliver software.

Applying Craftsmanship to Software Development Since craftsmanship is a tried and tested way of improving a community of practice, it is only natural to apply these ideas to software development. The benefits of doing this are:

• practitioners with broad and deep knowledge and experience, generalists rather than narrow specialists

• longevity of time in role to allow skills to develop

• long lived software as the creators maintain the application

• apprenticeship as an entry route so that there is an effective entry path

In an age of increasing specialization it might seems strange that one of the benefits of craftsmanship is that it promotes generalists. Unfortunately specialists are not very good at systems thinking, at addressing things from outside their speciality that might change the nature of the system. Practically the whole history of the twentieth century can be seen as one unintended consequence after another, all of them unseen by the specialists with the warning bells being rung by the generalist outsiders. In traditional crafts it is well known that the older a craftsman is, the better their work is likely to be. The reason for this is that skills improve as they are used, and the longer a skill has been practiced, the better a person is going to be at that skill. With software development, the time to become minimally competent is drastically shorter than traditional crafts because software is much more knowledge based. So books and teaching help to get newbie developers "up to speed" faster than manual crafts, but this faster knowledge acquisition is offset by the time it takes to develop a feel for software development. The feel aspect of software development is also why it is much better to have the original developers maintain software. Handing off software from the development team to the maintenance team is a great way to ensure that the value of that software decreases over time. The

handoff always fails because it takes a very long time to get the feel for an existing codebase. Strange as it may seem in our "post-industrial" age, apprenticeship is alive and well in many fields of endeavor. While manufacturing has taken over the domain of mass produced consumer items, the one off and custom creation is still the domain of the craftsman. Strange as it may seem, in the epitome of mass production the car assembly plant, the tool room is still the domain of the craftsman and time served apprentices. When a factory needs a special jig or some special welding, they have to turn to the craftsmen to fill

those needs. Software development is ripe for the craftsmanship model because it fits the paradigm of software development so neatly. We can copy existing software components really easily, so we have the manufacturing part well figured out. The problem of software development is the creation of custom solutions to specific problems. Just as we need a toolroom to create the tools for a

factory, software development is practically all tool building, and hence needs a craftsmanship approach.

Prospects for Software Craftsmanship The software engineering paradigm is well entrenched, so it might seem that an alternate approach to software is not going to happen. Luckily however there are several indicators that suggest the days of software engineering are numbered. The Free and Open Source Software community is one challenge to software engineering, and interestingly it is one community where the status of maintainers of software is high. The longevity of FOSS projects is in many cases better than comparable commercial software projects, and the continuity of the developers in FOSS projects exceeds that of practically every commercial project. It is not unusual to find that the lead maintainer for a FOSS project has been in the role for over 10 years. Small wonder then that the quality of the software in these projects is high. The Extreme Programming approach to software development is another challenge to software engineering. Rather than follow the software engineering approach of trying to document everything, it takes the approach of trying to spread the knowledge of the system across the team using pair programming. It also

Small steps towards craftsmanship

• We need to take ownership of the complete user experience of using our software.

• We need to undertake the long term stewardship of the software we create and the user data that is placed in our care.

• We should acknowledge that we make crappy, hard to use software and start working to make it better.

• We need to keep on expanding the sharing of knowledge within out community of practice

• We must push back against software engineering ideas that are contrary to craftsmanship, starting with the misguided ideas of checklists and best practices.


of 20

puts key design decisions into automated test cases so that compliance with the design decisions is automatically verified with each new revision of the software. There have even been a few experiments in applying the ideas of apprenticeship to software development. While the outcomes of these experiments have not been formally studied and evaluated, the fact that the experiments are taking place is encouraging.

Future of Software Craftsmanship It is premature for software developers to start calling themselves craftsmen. It is however time to start talking about the CRAFT of software development. We have however a long way to go before we can claim to be craftsmen. After all, most users of software have to put up with crappy software that should not have seen the light of day…

Pete McBreen is the author of Software Craftsmanship and Questioning Extreme Programming. He is an independent consultant who actually enjoys writing and delivering software. Despite spending a lot of time writing, teaching and mentoring, he does hands-on coding on a live project every year. Pete specializes in finding creative solutions to problems that software developers face. After many years of working on formal and informal process improvement initiatives, he took a sideways look at the problem and realized, "Software development is meant to be fun. If it isn't, the process is wrong." Pete lives in Cochrane, Alberta, Canada and has no plans to move back to a big city.

Books We Like

97 Things Every Programmer Should Know – Kevlin Henney – O’Reilly

With this book, you get 97 short and extremely useful programming tips from some of the most experienced and respected practitioners in the industry, including Uncle Bob Martin, Scott Meyers, Dan North, Linda Rising, Udi Dahan, Neal Ford, and many more.

They encourage you to stretch yourself by learning new languages, looking at problems in new ways, following specific practices, taking responsibility for your work, and becoming as good at the entire craft of programming as you possibly can. This wealth of practical knowledge contains principles that apply to projects of all types.

You can read the book end to end, or easily browse through to find topics of particular interest. "97 Things Every Programmer Should Know" is a useful reference and a source of inspiration. Tap into the knowledge of expert programmers who have earned stellar reputations. Learn the basic wisdom every programmer needs, regardless of the language you use. Take advantage of the online presence that has evolved from this book project.

Clean Code – Robert C. Martin – Prentice Hall

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way. Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it. What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.

CSS The Missing Manual – David Sawyer McFarland – Pogue Press

"Cascading Style Sheets" can turn humdrum websites into highly-functional, professional-looking destinations, but many designers merely treat CSS as window-dressing to spruce up their site's appearance. You can tap into the real power of this tool with "CSS: The Missing Manual". This second edition combines crystal-clear explanations, real-world examples, and dozens of step-by-step tutorials to show you how to design sites with CSS that work consistently across browsers. Witty and entertaining, this second edition covers more elements of CSS 3, as well as Internet Explorer 8.

Version Control with Git - Jon Loeliger – O’Reilly

Distributed source control has become the new trend in project management, particularly on open source projects, and Git is the leading tool in this area. Initially created to manage the distributed development of the Linux kernel, Git is now the revision control system favored by open source software developers. The flexibility of Git, however, means that users can misunderstand the proper way to use it or what the implications are of their updates and commits. This book, written by leading proponents of Git with extensive experience, examines real-world development environments and shows precisely how to use Git in each .


of 20

Peer-led Learning and Software Craftmanship

Peer Group Learning and Assessment is a new approach to helping teams of software developers to gain new skills - say Jason Gorman and Kerry Jones …

… it's an experimental coaching method that has had some early successes in a small number of pilot programmes at progressive organisations. Here they present two personal experiences of an initiative taking place in the TV Platforms section of the BBC, in White City, London.

Introduction Peer Group Learning and Assessment is a new approach to helping teams of software developers to gain new skills and to learn to apply those skills on their projects. It's an experimental coaching method that has had some early successes in a small number of pilot programmes at progressive organisations including the BBC. Here we present two personal experiences of the initiative in TV Platforms at the BBC in White City, London.

Why Peer-Group Learning & Assessment? (The External Coach - Jason Gorman’s – View)

I've been helping software developers to write "better code" since I went freelance in 1997. My experiences working with hundreds of programmers across a wide range of application domains and levels of ability, as well as my own personal experiences of learning disciplines like OO design, test-driven development and refactoring, have led me to some useful insights which I'm now applying with clients like the BBC. The programmers who learned and improved the fastest were invariably the ones who genuinely wanted to learn. The ones who gained little from coaching were the ones who weren't interested or motivated to learn. The key factor then was not how good I was at teaching programmers to do things the way I thought they should be done, but how motivated they were to learn in the first place. I resolved to try a different approach. By focusing on trying to inspire programmers so that they might want to learn, and on fostering an environment in which anyone who wants to learn and improve doesn't just feel, but in every practical sense, is supported in their efforts, I'm finding that the results are very encouraging indeed. Teams and individual programmers need to take ownership. They

must want to learn. They must want to write more maintainable and more reliable code. Programming computers is a practical skill, just like playing the guitar or riding a bicycle. For sure, there's knowledge that can be imparted by coaches like me. But ultimately knowledge isn't enough. Understanding how to ride a bicycle is not the same as being able to ride a bicycle. Knowing where the chords are on a guitar's fretboard is not the same as being able to play a song using those chords. I've worked with some very knowledgeable programmers and been shocked and dismayed upon reading their code. There's a world of difference between knowing what we should be doing, and actually doing it. The sad reality is that many programmers who say they do TDD and refactoring, for example, really don't. Not habitually, at least. From my own experience I know that programmers who aren't in the habit of doing things like writing a failing test before they write any new code, or always looking for duplication and refactoring it away, will almost certainly end up with poorer quality software. And how knowledgeable they are makes little difference if that knowledge doesn't translate into good habits. Peer-Group Learning and Assessment (PGLA) is a non-traditional approach to helping programmers and teams learn and improve at core disciplines. It's built on some basic tenets:

• People learn because they want to, and people learn best in groups where everyone else is keen to learn

• Building habits over longer periods is more effective than imparting knowledge in the short-term

• The best test of whether a juggler can juggle is to ask to see him juggle

• Organisations that offer practical support for learning, as opposed to just lipservice, will attract and foster better programmers

The software craftsmanship movement

Key Points

• The programmers who learned and improved the fastest were invariably

the ones who genuinely wanted to learn

• Peer-Group Learning and Assessment (PGLA) is a non-traditional approach to helping programmers and teams learn and improve at core disciplines

• People learn because they want to, and people learn best in groups where everyone else is keen to learn

• Building habits over longer periods is more effective than imparting knowledge in the short-term

• The best test of whether a juggler can juggle is to ask to see him juggle

• Organisations that offer practical support for learning, as opposed to just lipservice, will attract and foster better programmers

• The programmers who have successfully passed a peer assessment in "apprentice-level" TDD really can do TDD

• Showing how we develop software, providing constructive feedback and learning from our mistakes is essential for the development of software engineering as a discipline


of 20

has many schools of thought about how best to instill good habits and nurture professionalism and responsibility among programmers. Peer-Group Learning and Assessment is very much from the "learning by doing" school of software craftsmanship. There's no deep theoretical foundation or philosophy behind it. It simply groups together programmers who want to learn, helps them build a concensus about how they think something should be done, gives them a framework for focused and mindful practice over an extended period of time, and helps them to slowly but surely build up good habits. It also helps them to test their habits in a more meaningful and practical way, leading to a kind of peer-to-peer certification that addresses some of the shortcomings of traditional skill assessment techniques. It's still early days, but I've been very impressed with the results we've been getting. The programmers who have successfully passed a peer assessment in "apprentice-level" TDD really can do TDD. They're in the habit of doing the things they agreed in their groups that they should be doing. They write the assertion first. They always run the tests after even the smallest refactoring. They don't tolerate duplicate code and refactor mercilessly. They always run the test to make sure it fails for the right reasons. And so on. Each group has their own habits, and therefore each group has mastered their own school of test-driven development. It's theirs. They own it. And that's what really seems to make the difference. The pioneers who went through Peer-Group Learning and Assessment in TDD are now tackling the much more challenging discipline of refactoring. They have selected a matrix of common code smells and commonly-applied refactorings and will spend many hours over several months seeking out those smells in their own code and practicing their refactorings to eliminate them, all the while applying a set of good habits they have agreed to in their group like "use automated refactorings wherever possible" and "make sure there's adequate test assurance before refactoring any part of the code". Meanwhile, those same pioneers have become TDD coaches, helping new peer groups to define their own school of TDD and to build up the good habits they believe will lead to better code. This seems to increase the buy-in and ownership of the coaches to their own school of TDD. It also gives them ongoing practice at TDD to help maintain these habits, and from a new perspective, which is a great learning experience in itself. Peer-Group Learning and Assessment is more challenging, no doubt. And some organisations will certainly lack the will and the means to make it work for them. But because it is challenging, and because it really stretches programmers (and coaches), it is more rewarding. Peer groups feel like they're really achieving something. And they really are.

How we run Peer-Group Learning & Assessment (Peer-Group & Internal Coach Kerry Jones’s View)

Over the past nine years I've constantly been on a steep learning curve as a Software Engineer and as a Technical Architect and, as a result, I've become interested in how I learn to become an expert in specific skills and more generally how people learn. I'm also responsible for helping to find effective ways for our team of 40 software engineers to learn how to become expert software engineers. We've tried many different approaches to teaching software engineering skills, including sending all 40 engineers on the same training course and employing experts on a contract basis to pair with them on projects. The problem I have with week-long training courses and training performed in short bursts is that, as soon as you get back to work, you start forgetting what it is that you've learned. If you're not using that skill every day it's all forgotten far too quickly. I believe that deliberate and repetitive practice are much more effective ways to learn. If you're not forming habits by practicing a specific skill you will never get to the point where you start to gain a better insight. And that is essential to becoming an expert. There is research to validate these insights into learning. Mary Poppendiek has recently presented on the topic of Deliberate Practice in Software Engineering which references publications and summaries of the research field by Dr. K. Anders Ericsson. Becoming an expert in any specific skill relies on:

• The motivation of an individual to want to improve

• Having a mentor available who can design exercises based on the apprentices current skill level that will instill good habits and stretch the learner

• Deliberate practice and repetition of training exercises, and

• Immediate feedback so the learner can see the improvement in their performance.

Here I explain the Software Craftsmanship Programme Jason has introduced to us based around Peer-Group Learning and Assessment. We also reflect on what we've learned in the process of implementing it and show how we are creating an environment where everyone can learn to become better software engineers.

Software Craftsmanship Programme

We started our Software Craftsmanship Programme with an initial trial group of eight Software Engineers. Most of us were senior, so there was a fair amount of development experience within the group. But, as we quickly found out, we had a lot to learn, and still have. The programme consists of a number of groups of about eight engineers, including myself, progressing through various stages of practice, starting with the more fundamental skills and then moving on to the more challenging disciplines. Once one group has


of 20

successfully passed their assessment - which means they have been found by their peers to consistently apply the good habits their group has agreed on - they are then qualified to become coaches at that level of skill and work with a new group of apprentices to help them build a similar set of good habits. At the same time as coaching new peer groups, the people from the first group move on to learning a different skillset or a more advanced level of practicing an existing discipline. For each group, the process is the same:

• Choose the skill that you'd like to improve

• Attend an orientation day with an expert in the chosen skill and a number of coaches to develop the group's Skill Worksheet

• Pair with others in your peer group, the coaches and the expert until your Skill Worksheet is completed

• Complete an assessment day where all the peers of the group mark each other and decide on who should pass or fail

• Rinse and repeat That's it in a nutshell, but there is a lot more detail in each of these phases that needs to be explained and understood, so let's start.

Choosing the skill

For groups new to this process, choosing the skill they'd like to improve can be challenging. However, there is one skill that we believe to be a fundamental basis for the rest of the software engineering practices. That is Test Driven Development (TDD). As a result, all three of our groups have started with "Apprentice-Level" TDD. Our first group after passing the Apprentice Level TDD have moved on to Apprentice Level Refactoring and are also coaching the two new groups in TDD. Each group has eight software engineers with varying skills and experience. It's important to highlight here that noone in our 40-person software engineering team is exempt from this programme. It doesn't matter how expert you think you are at a specific skill one of the most important features of this way of working is Peer Learning. Everyone in the group is learning from each other. It's important to have an expert who isn't part of the group pair with all the members of the group at least once, however it's up to the group to organise pairing sessions with the peers in their group and to help each other complete their individual Skill Worksheet. If you are lucky enough to have people who really are experts in the skill participating in the group then it gives them a great opportunity to help teach everyone else in the group. I also firmly believe that an expert will also learn a lot from the peers in the group.

Orientation Day

The orientation day is facilitated by an expert in the skill who spends the first hour or so demonstrating the skill, explaining what they do and the habits they have developed and what they believe to be important. The goal of the orientation day is for the members of the peer group, excluding coaches and the expert, to choose and agree on a set of 10-12 good habits that they will have adopted in relation to the specific skill. These habits will form the basis of the Skill Worksheet for this group and they are what each of the peers will assess each other on during the assessment day to determine if they have passed or failed. Our peer group choosing and agreeing on the 11 habits that we wanted to adopt was an important aspect of our peer learning. It created a sense of ownership amongst the group. We had in fact created our own "brand" of TDD and for the first time all eight of us agreed on what TDD is, or at least what it is to us. We had an established set of good habits that we wanted to learn and we had all bought into them. We were influenced by the expert in the room but the expert needs to facilitate the discussion and to explain the reasoning behind why they feel a specific habit is important. The expert can also explain why other habits are bad and provide insight into why they are not worth adopting. Ultimately the decision on which habits to choose is entirely up to the peer group. As this was apprentice level TDD we

decided to leave more complicated areas of TDD like mock objects out of this round and to introduce them during the next journeyman level of TDD. We also decided to leave anything that was a bit controversial out of apprentice level TDD and chose to discuss and possibly adopt them again once we start the journeyman level TDD.


of 20

The Skill Worksheet

Each individual in the peer group receives a Skill Worksheet that will look something like Figure 1 (see earlier page). Our worksheets were designed to give every member of the group at least 55 hours of pairing with their peers and/or a coach while strictly following the habits on the worksheet. The worksheets are completed when all of the boxes on the sheet have been filled in by someone from your peer group. To fill in a box or set of boxes a peer must have worked with you for at least an hour and confirmed that you followed the habits listed on the sheet. Pairing sessions were two hours long and would involve ping-pong pairing or passing control of the keyboard after the first hour. During the pairing session the person being signed off chooses a maximum of four habits to concentrate on for this pairing session. At the end of the session, if your pair agrees that you followed those habits for the entire hour, they put their initials in the relevant boxes. If you're not the person at the keyboard during a pairing session then your job is to point out where your pairing partner is not following the agreed good habits. The pairing sessions force every software engineer to perform the skills over and over again, reinforcing the learning until the good habits we had chosen became second nature. By the time we had reached the end of our worksheet we were doing TDD with a good bunch of habits automatically. We didn't have to think about the process any more. Some of us actually started to feel uncomfortable if we saw someone do a refactoring and leave it too long before they ran the tests again. Completing the worksheets in this way meant that we were setting aside time to deliberately practice TDD. Sometimes we were working on real code bases and sometimes we were working on a set of TDD practice examples but throughout it all we were deliberately practising TDD and repeating training exercises.

Assessment Day

The assessment day was hard, even after setting aside time over the previous four months to practice. One of the reasons it was hard was that one of the major goals of the day was to prove that we could TDD all day and maintain the good habits that we had been practising without making too many mistakes. The day was split into coding sessions of an hour. Each session was recorded using a screen capture tool, like Camtasia Studio. After each session, we would swap desks and watch back the recording of one of our peer's sessions, keeping an eye out for any instances where they failed to apply one of the good habits we had agreed on in the orientation. If we spotted them failing to apply a habit (e.g., refactoring when the test was failing), then we would put a big "X" on an empty worksheet against the habit we caught them breaking. If you got three or more X's during any 1-hour coding session, you failed the assessment. If one of the sessions was done in a pair,

then both members of that pair either passed or failed together, so it didn't matter who was typing and who was navigating when the mistake was made. This is what we did on the assessment day:

• Individually record yourself solving a pre-defined problem using TDD in 2 x 25min sessions with a 5 minute break in between.

• Swap desks with someone from your peer group and mark your peer's session using a blank skill worksheet

• 30min break

• Pair with someone from your peer group to solve a pre-defined problem using TDD in 2x25min sessions

• Swap desks with a different pair from your peer group and mark their session

• 1hr lunch break

• Individually record yourself solving a pre-defined problem using TDD in 2x25min sessions

• The group expert marks this final recording and because he has eight hours of sessions to get through these are not marked on the day

What we found and what we changed as a result

One of the most important ideas behind peer learning and the worksheet is that you need to set aside lots of time to practice. A few of the engineers in the first group found it hard to set aside the time required to complete their worksheet. In both cases this was because of major project deadlines where one person was working on projects that didn't involve writing any code and another was working in a language that doesn't have good enough tool support for unit testing or refactoring. They found it hard to take time outside of their projects to do the practice they required. This highlighted the fact that you absolutely need support from senior stakeholders in implementing a programme like this. If the support doesn't come from high enough in the company it is difficult to find the time to complete the worksheet.. To allow these two engineers to complete the worksheet we pushed the date of the assessment back one month and I worked with their project manager and line manager to help them find the time they needed to complete the worksheet. An engineer who is aiming to complete a worksheet really needs to set aside a minimum of two hours a week to pair with someone in their peer group. Anyone who didn't do this found it hard the closer we got to the assessment day because they had too many pairing sessions to complete and were struggling to fit them in around their other work. If you left most of your pairing sessions towards the end, you were effectively cramming for an exam. A result of the cramming is that you don't pick up the habits as well as other engineers and have to concentrate more on the assessment day and don't do as well on the assessments. To get around this issue and make sure peers are pairing every week, we've introduced a weekly stand-up so that peers can


of 20

check each others progress on their worksheet and organise some time that week to pair. Two engineers in my group found it easy to complete the worksheet within a couple of months because they were working on the same project together and were already using TDD on the project. As they were developing new features at work for one of our products they were also able to sign each others worksheet, and it was possible for them to spend the two hours required for a pairing session almost every day. This is the most effective way to complete a worksheet with minimal disruption to your daily work. Towards the end of our worksheet, a mock assessment was introduced where we set aside a day to go through an assessment as if it was a real assessment day. When we did this most of us failed. It was a valuable experience because we had still not developed the habits we were hoping to by this point. This left us with some time to practice more and to work on the areas which hadn't become habits. It would have been better if these were corrected early on, so in future groups we will be performing a mock assessment when they are about half-way through completing the worksheet. Once my group had successfully completed apprentice-level TDD, we became coaches for the next two groups starting their apprentice-level TDD. A promising sign is that, the responsibility of leading and coaching new groups through the same process, the peers from my group are showing greater enthusiasm for the programme. They are now seen as coaches of a specific skill within the department and feel empowered because they help define and drive the process and are starting to teach our other software engineers.

Gathering Empirical Evidence

One of the areas that Jason and I are interested in is how we can use software metrics to gather empirical data and evidence of the improvement in code quality as a result of the Peer-Group Learning & Assessment (PGLA). What we will be looking for in the future is a way to demonstrate more objectively that software is better tested, simpler and easier to change. We don't yet have enough data to provide conclusive proof that the software craftsmanship programme improves the quality of our code. However, the initial results are encouraging, as indicated in Table 1. .

In Table 1 - LOC is the Lines of Code, Line/Branch Coverage refers to the unit test code coverage and Complexity is measured using (Cyclometric Complexity / the number of methods). Each of the rows in Table 1 is a Java code base developed by software teams that were made up of a few people who were participating in the TDD apprentice-level training, and some who weren't. The software in the top section was developed before the TDD apprentice-level coaching started. The software in

the bottom section existed before we started our first peer group but has been developed further since the introduction of PGLA. The software in both sections has been developed by teams involving engineers in the first TDD peer group before and after their TDD apprentice-level assessments. Keith Braithwaite's research on measuring the effect of TDD shows what we expect to be different in code that is developed using TDD. Rather simplistically, we expect the code to be better tested and for classes and methods to be less complex. To give us a simple indication of this at first we've chosen to use code coverage, percentage of long methods, average method complexity and percentage of duplicate code. What's interesting about these results is that the code developed before the TDD apprentice-level peer group started was actually developed using what the engineers believed at the time to be TDD. After completing the TDD apprentice-level assessments, the code coverage seems to be increasing and the overall complexity and length of methods is decreasing along with the amount of duplicate code, which is a promising trend.

Conclusion The first group of TDD apprentices, including myself, was run as a trial within our department so we could assess the benefits of the peer learning approach. As the Technical Design Authority (TDA) for our code bases, being a part of a peer learning group has been a real eye-opener. Although we only have a small amount of empirical evidence that the software quality has improved, it's obvious when pairing with those of us who have passed the TDD assessment that the quality of the

Before TDD Apprentice Peer Learning

LOC Line Coverage Branch Coverage Complexity/method Complexity/Class

2055 90.5% 86.8% 2.2 11.2

890 50.1% 40.7% 2.2 9.3

4553 65.3% 52.9% 2.3 11.6

6154 100.0% 100.0% 2.3 8.1

During and After TDD Apprentice Peer Learning

LOC Line Coverage Branch Coverage Complexity/method Complexity/Class

1831 92.9% 88.7% 1.7 5.9

1416 90.4% 61.3% 1.6 5.9

Table 1: Software Metrics of projects developed by the team before, during and after the TDD apprentice-level assessments


of 20

new code we're producing has improved. The code is better tested, the engineers are regularly improving the design of existing code, and, because the new code is developed using TDD, the new code is more modifiable and maintainable than our previous software projects. So far we've not publicised our software craftsmanship programme to departments outside of our own. However, the buzz created by our software engineers and managers is starting to get noticed in other departments. Managers who are running software teams close to us recognise the value of helping their software engineers improve and work towards becoming experts, and are starting to ask questions about what we're doing. One of our goals in future is to find out if there's enough appetite from other departments, and to work with them to help spread PGLA to help more software engineers become experts. The feedback from the first group of engineers and coaches, as well as the improved quality of the code we are now producing, has allowed us to get the funding approved to scale up the peer-group learning for TDD apprentice-level to two more groups of eight engineers, and to start the first peer group on the refactoring apprentice-level. Now that 16 new engineers are starting their TDD apprentice-level, and the results of the first group are becoming visible, being a part of the peer-group learning programme has become something that most - if not all - of our software engineers really want.

As we've not been able to scale the process any more quickly, there are a number of engineers who were upset at not being included in one of the new peer groups. They've heard stories from the first peer group about just how much they have learned and improved over the past six months. There's a real sense of achievement in passing the peer-group assessments, and that's been noticed by everyone in our team. Passing the TDD apprentice-level assessment is a goal that's also been written into some of our software engineers' yearly appraisals, which shows our commitment to continuing with this programme in the immediate future. I believe in learning by doing. The Software Craftsmanship movement that has grown in recent years is great because more than ever software engineers are showing each other how they write code. Showing how we develop software, providing constructive feedback and learning from our mistakes is essential for the development of software engineering as a discipline. Peer-Group Learning and Assessment promotes shared learning and creates an environment where people take responsibility for learning and practising. It provides a structure where software engineers can learn from a mentor, allocate time for deliberate practice and get immediate feedback during pairing sessions and assessments on their performance.

Jason Gorman is a director of Codemanship Ltd and has coached hundreds of professionals in the key disciplines of software craftsmanship. His web site parlezuml.com has been visited by more than 1 million people since 2003. He chaired the first international conference on Software Craftsmanship in 2009, and contributes to other conferences including XPDay, Software Practice Advancement and CITCON. He is also executive producer of "Boffoonery!", a comedy benefit in aid of Bletchley Park. Kerry Jones is a Technical Architect who specialises in broadcast and digital media. He works in the TV Platforms Group of BBC Future Media & Technology, the team responsible for delivering the BBC Red Button service and interactive applications including BBC iPlayer on internet connected TVs. He was also on the review panel for papers submitted to Software Craftsmanship 2009.


It’s easy. You link to ObjectiveView using our linkgif, and your logo will appear on all copies of the magazine. Email

[email protected]


of 20

Design Driven Testing

TDD certainly seems to be a hot topic – but are there alternative approaches that can yield the benefits of

testing? In this article Doug Rosenberg and Matt Stephens ably assisted by Aaron Bell and Tom O’Reilly discuss

Design Driven Testing. DDT is an approach to testing that bases test cases on design work that has already been completed. In this article we will explain how this works, using the ICONIX extensions to Enterprise Architect (Sparx System) to illustrate the points. Let’s consider a simple Login use case, which satisfies 3 Requirements:

Using Enterprise Architect we can automatically generate a Robustness Diagram using the Agile/ICONIX plug-in. Of course, you can do this manually on a white board if you want to ☺.

By analyzing our use case using the Robustness Analysis technique, we’ve added a lot of information to the model that can be used to drive the testing of the application. So we can create a test case for each “controller” on the Robustness diagram:

We can also choose to generate or create test cases for our Requirements:

In some organizations, the development team might own the “controller tests” while an independent QA team might own the “requirement tests”. Once we’ve generated the test cases, we can add test scenarios. In this example shown, we’re adding scenarios to the test case that validates the format of a password. We need to check that the password is of the required length, contains a mix of alpha and numeric characters, and is a mix of upper and lower case.


of 20

From here we can create a test plan for the testing. In the example shown the reports are generated automatically using Enterprise Architect’s built-in report generation capability. Driving our testing activity from the model is very straightforward whether an automated or manual approach is taken.

From here, we need to create test classes that can be used in testing frameworks such as JUnit or NUnit. Using EA this can be done automatically – but in any case the mapping to code should be clear. Here’s the test case class:

And here’s the code that can be generated or written from it:

A similar approach can be adopted using test cases generated from sequence diagrams. You can find out more about this at the following URL: http://www.iconixsw.com/Articles/ddt_tutorial.html So summarising, we’ve shown that there is a logical route from requirements through to test cases that can be implemented using tools like Junit or Nunit. A broader view of the whole testing process is shown below.

The process we’ve discussed here doesn’t actually preclude TDD, and is in many ways complementary to it. Once the test cases classes have been fleshed out, additional test detail can be added in classic TDD style, and the tested class(es) can be developed to meet the new test. We’ll leave that choice to you…


of 20

Understanding the Role of an Agile Coach

An agile coach is not going to help you get a washboard stomach. Is not in the personal fitness business, but works with software development teams to help them improve their performance and

get the benefits of applying agile principles to their work, explains Rachel Davies – author of Agile Coaching…

Introduction I’ve worked as an agile coach for years now and still find that the role is not widely understood in the software industry. I hooked up with Liz Sedley to get more information out there about the role, the result is the first book on "Agile Coaching" [1]. Let's explore here what an agile coach does and why this role is so crucial to succeeding with Agile.

Becoming an Agile Coach Once upon a time, I was a software developer immersed in my own little world of software architecture and design. I was often oblivious to what my colleagues were working on until we attempted to integrate our work, and then entered a world of pain. How could we work more effectively to avoid interminable periods of rework? Luckily, I came across Extreme Programming (XP) in 2000. XP sounds crazy; developers write tests before coding, they program in pairs, and integrate continuously. I was desperate enough to try it and delighted to find that delivering software iteratively works well. I became an agile coach because teams find it hard to get started with XP and it helps to get some experience on board to draw on. Nowadays, I’ve broadened out and help teams use techniques from a wider set of Agile methods than XP. I won’t dwell on the pros and cons of Agile methodology here. As you’ll discover, an agile coach's domain is team collaboration and how the work is organized.

Contrasting the Role of Agile Coach with Other Roles In a nutshell, an agile coach helps a team work out how to apply the principles of agile software development [2] to their projects. It takes time to adopt these changes so you can’t do this effectively as a "seagull consultant" or trainer who swoops in to deliver words of wisdom and then makes a sharp exit. You need to spend time with a team to help them to become more aware of their workflow and how to collaborate effectively. How is being a coach different from a team lead or project manager job role? Well, it’s not incompatible. The difference is that these roles have a wider set of

project and company specific responsibilities, such as reporting progress, performance appraisals, etc. I notice that the pressure to deliver can distract from process improvement. Whereas, if you work solely as an agile coach, you don't have responsibility for project deliverables and administriva. Being a coach is also different because it’s transitory role not tied into project duration. Your goal is for the team to become self-coaching and adept in applying agile then you move on. That doesn’t limit agile coaches to introducing agile into organizations and establishing new agile teams. The majority of the teams that I coach are already applying agile techniques and seek coaching because they want to boost their performance and proficiency in agile software development.

Drawing from Other Coaching Fields You can see why people get confused about what agile coaching is because the term coaching is used more widely in non-software contexts. For instance, you may associate coaching with sports and also self-help techniques. Let's take a closer look at how these overlap with agile coaching. Business and life coaches usually work with individuals on a one-to-one basis. They help their “coachees” uncover personal goals and work out how achieve them. As an agile coach, your primary focus is team performance towards company goals rather than the personal growth of individual team members. Of course, you’ll find that you often have to work with individuals to improve teamwork. So you can draw on techniques from life-coaching to help people gain perspective on their work and open their eyes to new possibilities. However, I'd say that life-coaching skills are not sufficient. An agile coach has to bring a broader set of skills to a software development team than simply clarifying goals and working out required actions to achieve them. Sports coaches share the same focus of building a team that performs effectively. They require a deep knowledge of their sport and are often former players. They work on skills, tactics, and motivation. An agile coach wants to help teams with the same things — although techniques for building up physical sports skills don't really transfer into the world of software development. Instead, you can encourage developers on your team to improve as craftsmen and practice their code kata through coaching dojos [3]. So we see an agile coach can draw from both these coaching fields.


of 20

Understanding Core Skills The core skills for coaching agile teams are solid communication skills, such as listening, asking questions and giving feedback. To engage with the whole team, you must go beyond one-to-one conversations and enable effective team conversations. So meeting design and facilitation are also core skills for agile coaches. This year I've run workshops with coaches at Agile and XP conferences to introduce Richard Hackman's model for coaching interventions [4]. He defines a coaching intervention as “any action that seeks to minimize process losses or to foster process gains.” He goes on to identify three categories of coaching intervention:

• Educational interventions improve understanding and skills on the team.

• Consultative interventions foster process improvement by helping the team become more aware of their (mindless) habits.

• Motivational interventions improve effort by building shared commitment and minimizing free-riding.

The big eye-opener for most agile coaches, who took part in these workshops, is that they usually focus on educating teams in agile practices and how to improve their agile process but they neglect motivation. Notice where team members are coasting along and not pulling their weight, now explore why. Think about ways that you can re-engage each team member. You can make a start by bringing them together to establish shared goals that they believe are achievable and open up team discussion of what’s in it for them.

Where Software Design Experience Helps You might be surprised to learn that many of the skills that we acquire as a software developers also come in handy as coaches. Much of our work is to help teams “debug” their agile process by making them more visible and inspecting what’s revealed. We follow the work through the team from concept to delivery and help the team to become more aware of inputs and outputs along the way. We prompt them to get their brains in gear and find ways they can adapt their processes to raise and handle exceptions smoothly.

Object-oriented thinking also helps us see opportunities for refactoring team process. Our team needs to get the coupling and cohesion of the work right to improve the flow of software deliveries through the team. Many activities in the Agile lifecycle can be decoupled. For example, a planning meeting can be broken into different sections that are run as separate meetings;

doing this helps keeps the meetings shorter and more focussed. We can also apply the Once-And-Only-Once principle to remove duplication of information which when spread around a plethora of tools (such as wikis, defect tracker, index cards, spreadsheets) can be a source of confusion and lead to important aspects of requirements

being missed. When you make the right information easy to find then decisions can be made swiftly by the team.

Bringing It All Together When you're engaged as an agile coach, don't be surprised if your clients have some strange ideas about what an agile coach does. They may expect all coaching to happen in a series of meetings far away from the team. You’ll need to educate them about the role and explain that spending time with the team while they’re at work is an essential part of coaching. Before you get started, hone your communications skills for one-to-one conversations and team meetings. Draw from the fields of life-coaching and sports coaching for ways to unleash intrinsic motivation. Now you can apply your existing experience in software development, to lead teams to debug and refactor their agile process. If all that seems like a tall-order, start simple. Engage your current team by making their process more visible and then reflect with them on what’s revealed.

References 1."Agile Coaching" by Rachel Davies and Liz Sedley ISBN: 978-1934356432 2. Agile Manifesto: http://www.agilemanifesto.org/principles.html 4. Coding Dojo: http://www.codingdojo.org 3. "Leading Teams: Setting the Stage for Great Performances" by J. Richard Hackman ISBN: 978-1578513338

Rachel Davies works as an agile coach helping teams adopt and improve their agile delivery capability. Her new book "Agile Coaching" shares many practical tips that can help you take your teams to the next level. Rachel supports the agile community as a long-serving director of the Agile Alliance and as an organizer of many Agile conferences.

As an agile coach you should:

• Examine how the role of agile coach compares with other roles, such as trainer, consultant, and manager.

• Appreciate how agile coaching compares to coaching in other domains like sports and life-coaching.

• Learn about the Hackman model of coaching interventions.

• Discover how agile software design skills apply to agile coaching.

• Understand the core skills will help you become an effective agile coach.


of 20

Books We Like

jQuery Cookbook – Cody Lindley – O’Reilly jQuery has emerged as the most popular Ajax framework, outpacing options such as Dojo and the Prototype JavaScript Framework. jQuery Cookbook shows how to add components from the jQuery library to your websites and web applications, with detailed recipes for tasks ranging from basic integration to complex user interface development.

Scaling Lean & Agile Development – Craig Larman / Bas Vodde - Addison-Wesley Professional, Increasingly, large product-development organizations are turning to lean thinking, agile principles and practices, and large-scale Scrum to sustainably and quickly deliver value and innovation. However, many groups have floundered in their practice-oriented adoptions. Why? Because without a deeper understanding of the thinking tools and profound organizational redesign needed, it is as though casting seeds on to an infertile field.

Drawing on their long experience leading and guiding large-scale lean and agile adoptions for large, multisite, and offshore product development, and drawing on the best research for great team-based agile organizations, Craig Larman and Bas Vodde share the key thinking and organizational tools needed to plant the seeds of product development success in a fertile lean and agile enterprise.

Agile Software Development – Robert C. Martin – Prentice Hall Written by a software developer for software developers, this book is a unique collection of the latest software development methods. The author includes OOD, UML, Design Patterns, Agile and XP methods with a detailed description of a complete software design for reusable programs in C++ and Java. Using a practical, problem-solving approach, it shows how to develop an object-oriented application—from the early stages of analysis, through the low-level design and into the implementation. Walks readers through the designer's thoughts — showing the errors, blind alleys, and creative insights that occur throughout the software design process. The book covers: Statics and Dynamics; Principles of Class Design; Complexity Management; Principles of Package Design; Analysis and Design; Patterns and Paradigm Crossings.

check out ovmag.com


It’s easy. You link to ObjectiveView using our linkgif, and your logo will

appear on all copies of the magazine.

Email:

[email protected]


of 20

97 Things Every Programmer Should Know

There is an art, craft, and science to programming that extends far beyond the program says Kevlin Henney. The act of

programming marries the discrete world of computers with the fluid world of human affairs…

Programmers mediate between the negotiated and uncertain truths of business and the crisp,

uncompromising domain of bits and bytes and higher constructed types. What this means in practice is that programmers have a lot on their minds. Programming languages, programming techniques, development environments, coding style, tools, development process, deadlines, meetings, software architecture, design patterns, team dynamics, code, requirements, bugs, code quality. And more. A lot. There's no small amount of wisdom scattered around the blogosphere, but mostly hidden in a morass of somewhat less-than-wise advice. Sound advice can also be found lurking within a number of books -- and, again, bookish form is no guarantee of quality. But most of the good stuff is locked up within the minds and experiences of practitioners. How to unlock some of this know how? A while ago I found myself reflecting on some code I'd seen -- "Dammit, that's just one of those things every programmer should know!". I had contributed to Richard Monson-Haefel's 97 Things Every Software Architect Should Know project and I knew that Richard had been working with O'Reilly to create a 97 Things series. My own mutterings were the trigger: what about doing for programmers what had already been done for software architects? A collective and open project based on voluntary contributions from programmers and others involved in the software development process. A cross section of people that would include big names — but, importantly, not just the big names. Although not strictly open source, the project has some open-source qualities. In particular, contributions are made under a non-commercial license (Creative Commons, in this case). Individuals contribute blog-length items on, well, things that they think every programmer should know. These items can be reused, repurposed and republished freely. There is also an element of crowdsourcing: taken together the items form part of a big picture, but the big picture is built up by sampling the wisdom of crowds rather than working to a design vision and progressively elaborating each detail as necessary. The writing is not collaborative and there's no intent that contributions should follow a common style or dovetail together like modular parts. If anything, the converse is true. Of course, neither the web site nor the book of the site provides a definitive definition of everything programmers should know. It takes a more sampled and constrained approach and, for that, is probably more

interesting and accessible to many would-be readers. Each item is sufficiently brief that it makes for a good discussion piece, such as in a reading group, or something to digest over a build or download. You can find the 97 Things Every Programmer Should Know site at http://programmer.97things.oreilly.com. You can follow it on Twitter as @97TEPSK. The book is listed at http://oreilly.com/catalog/9780596809492. There is an InfoQ piece about 97 Things Every Programmer Should Know and the 97 Things series at http://www.infoq.com/news/2009/09/97-things. To whet your appetite, here are a couple of articles from the book itself…

Code Is Design – Ryan Brush Imagine waking up tomorrow and learning the construction industry has made the breakthrough of the century. Millions of cheap, incredibly fast robots can fabricate materials out of thin air, have a near-zero power cost, and can repair themselves. And it gets better: Given an unambiguous blueprint for a construction project, the robots can build it without human intervention, all at negligible cost. One can imagine the impact on the construction industry, but what would happen upstream? How would the behavior of architects and designers change if construction costs were negligible? Today, physical and computer models are built and rigorously tested before investing in construction. Would we bother if the construction was essentially free? If a design collapses, no big deal — just find out what went wrong and have our magical robots build another one. There are further implications. With models obsolete, unfinished designs evolve by repeatedly building and improving upon an approximation of the end goal. A casual observer may have trouble distinguishing an unfinished design from a finished product. Our ability to predict time lines will fade away. Construction costs are more easily calculated than design costs — we know the approximate cost of installing a girder, and how many girders we need. As predictable tasks shrink toward zero, the less predictable design time starts to dominate. Results are produced more quickly, but reliable time lines slip away.


of 20

Of course, the pressures of a competitive economy still apply. With construction costs eliminated, a company that can quickly complete a design gains an edge in the market. Getting design done fast becomes the central push of engineering firms. Inevitably, someone not deeply familiar with the design will see an unvalidated version, see the market advantage of releasing early, and say "This looks good enough."

Some life-or-death projects will be more diligent, but in many cases consumers learn to suffer through the incomplete design. Companies can always send out our magic robots to 'patch' the broken buildings and vehicles they sell. All of this points to a startlingly counterintuitive conclusion: Our sole premise was a dramatic reduction in construction costs, with the result that quality got worse.

It shouldn't surprise us the above story has played out in software. If we accept that code is design — a creative process rather than a mechanical one — the software crisis is explained. We now have a design crisis: The demand for quality, validated designs exceeds our capacity to create them. The pressure to use incomplete design is strong.

Fortunately, this model also offers clues on how we can get better. Physical simulations equate to automated testing; software design isn't complete until it is validated with a brutal battery of tests. To make such tests more effective we are finding ways to rein in the huge state space of large systems. Improved languages and design practices give us hope. Finally, there is one inescapable fact: Great designs are produced by great designers dedicating themselves to the mastery of their craft. Code is no different.

Code in the Language of the Domain – Dan North

Picture two codebases. In one you come across:

if (portfolioIdsByTraderId.get(trader.getId())

.containsKey(portfolio.getId())) {...}

You scratch your head, wondering what this code might be for. It seems to be getting an ID from a trader object, using that to get a map out of a, well, map-of-maps apparently, and then seeing if another ID from a portfolio object exists in the inner map. You scratch your head some more. You look for the declaration of

portfolioIdsByTraderId

and discover this:

Map<int, Map<int, int>> portfolioIdsByTraderId;

Gradually you realise it might be something to do with whether a trader has access to a particular portfolio. And of course you will find the same lookup fragment — or more likely a similar-but-subtly-different code fragment — whenever something cares whether a trader has access to a particular portfolio. In the other codebase you come across this:

if (trader.canView(portfolio)) {...}

No head scratching. You don't need to know how a trader knows. Perhaps there is one of these maps-of-

maps tucked away somewhere inside. But that's the trader's business, not yours.

Now which of those codebases would you rather be working in?

Once upon a time we only had very basic data structures: bits and bytes and characters (really just bytes but we would pretend they were letters and punctuation). Decimals were a bit tricky because our base 10 numbers don't work very well in binary, so we had several sizes of floating-point types. Then came arrays and strings (really just different arrays).

Then we had stacks and queues and hashes and linked lists and skip lists and lots of other exciting data structures that don't exist in the real world. "Computer science" was about spending lots of effort mapping the real world into our restrictive data structures. The real gurus could even remember how they had done it.

Then we got user-defined types! OK, this isn't news, but it does change the game somewhat. If your domain contains concepts like traders and portfolios, you can model them with types called, say, Trader and Portfolio. But, more importantly than this, you can model relationships between them using domain terms too.

If you don't code using domain terms you are creating a tacit (read: secret) understanding that this int over here means the way to identify a trader, whereas that int over there means the way to identify a portfolio. (Best not to get them mixed up!) And if you represent a business concept ("Some traders are not allowed to view some portfolios — it's illegal") with an algorithmic snippet, say an existence relationship in a map of keys, you aren't doing the audit and compliance guys any favors.

The next programmer along might not be in on the secret, so why not make it explicit? Using a key as a lookup to another key that performs an existence check is not terribly obvious. How is someone supposed to intuit that's where the business rules preventing conflict of interest are implemented?

Making domain concepts explicit in your code means other programmers can gather the intent of the code much more easily than by trying to retrofit an algorithm into what they understand about a domain. It also means that when the domain model evolves — which it will as your understanding of the domain grows — you are in a good position to evolve the code. Coupled with good encapsulation, the chances are good that the rule will exist in only one place, and that you can change it without any of the dependent code being any the wiser.

The programmer who comes along a few months later to work on the code will thank you. The programmer who comes along a few months later might be you!

Kevlin Henney is a freelance trainer, consultant and regular speaker at international conferences – see www.curbralan.com. Dan North writes software and coaches teams in agile and lean methods. He believes in putting people first and writing simple, pragmatic software. He believes that most problems that teams face are about communication, and all the others are too. This is why he puts so much emphasis on "getting the words right," and why he is so passionate about behavior-driven development, communication, and how people learn. He has been working in the IT industry since he graduated in 1991, and he occasionally blogs at http://dannorth.net Ryan Brush is a director and Distinguished Engineer with Cerner Corporation, where he has worked since 1999. He is primarily interested in the application of technology to healthcare.


of 20

Design For Test – Opinion – Rebecca Wirfs Brock

Does the test code have to come first? It sounds straightforward. Write your test code first, then write

code to pass that test. Don't write an inch of code without writing a test first. That is what test-driven development (TDD) is about: Use tests to drive out the design and implementation. Rinse and repeat. Repeat many times a day. I know a number of top notch developers who are masters at their craft. Yet they don't daily program in a pedal-to-the-metal test-first-only write-the-barest-amount-of-code-to pass the test style. Yet they value testing. Testing, to them, is integral to programming. I asked a few of my programmer buddies who value

testing what does it mean to design for test (I have my ideas, but I don't make my daily living writing production code)...even if they aren't TDD followers. And the bottom line is this: code that is designed for test must continually be tested (not necessarily at the speed of a TDDer). If you want to make testing feasible, you often need to make code-under-test easy to isolate from its production environment, tunable, and measurable. Not easy stuff. Just like design flexibility, testing doesn't come for free. It's part of a disciplined development process.

Rebecca Wirfs-Brock is a software development consultant with Wirfs-Brock associates. See http://wirfs-brock.com/


It’s easy. You link to ObjectiveView using our linkgif, and your logo will appear on all copies of the magazine. Email

[email protected]

ObjectiveView - Nagafixusers.nagafix.co.uk/~mark/ovmag/OV11.pdf · objectiveview – ovmag.com –...

Documents

Transcript of ObjectiveView - Nagafixusers.nagafix.co.uk/~mark/ovmag/OV11.pdf · objectiveview – ovmag.com –...