At the last meeting of our monthly agile get togethers (which was really nice) we talked about a bunch of things; one being how to help teams keep using techniques that are helpful and reflect on what they do so that they may find new helpful techniques.

 

At my current short assignment I am helping a team with their process and their work and we have been talking about these things, so the discussion was very useful to me. The reward of task completion and (if you have a quick feedback cycle via some receiving customer standing by) delivery is huge and it can be hard to provide an alternative mechanism that rewards refactoring and design investments.

 

One type of tool I find useful to get a grip on group dynamics are the personality catalogs a'la DISC. There is a correlation between the personality types of such models and preferred rewards, "Drivers" are more focused on task completion and delivery, for example. However, the model notes a tendency or potential factor, it is not static - the challenge is to affect this focus in a beneficial direction, usually so that more design effort is undertaken.

 

There is little point in enforcing policies by means of negative reinforcement. At AgileOresund we discussed how to stimulate a feeling of professionalism / "professional pride" so that there will be more care taken in how things are accomplished than just that they are accomplished.

 

I feel that this can be approached via a general belief and support of the individual, and a stimulation of his/her personal goals. These goals are often in line with the goals of the organization, and create a much greater drive. A dialogue aimed at this is often neglected in companies today: Many companies I've been to lack leaders who have the ability to create a solid and effective conversation of this type. In contrast, the "actual" leaders (may be team leads or just in terms of the socially context, due to age and experience) are sometimes not interested and/or do not have time and do not prioritize this important conversation. I feel that this is a loss for everyone - the companies, the industry as a whole and the individuals.

 

Another perspective on this discussion is the model of developers that microsoft uses, and there has just recently been some controversy around how it was recently expressed at a blog. Microsoft uses a set of persona that represent different developers. In a recent post - an discussion of code production and tools - quality and needs were presented based on one of the persona, Mort. Mort is the least technically interested developer, that merely wants to get the job done, and the code he produces does not fit in a complex codebase that will need to be maintained over a long period of time, and so on, it is posited. There follows (and it is still active) a heated and fairly interesting discussion, where people mostly disagree with how the original poster related Mort and his view of the world to agile practices.  Regardless, using these persona as an analysis tool in this way feels clumsy to me, I don't think that it is what they were intended for. 

 

Yet it does send a thought to my rewards analysis: If we accept the persona model as useful, and think about the Mort persona in a typical scenario, I think that Morts in general will be aware that they are not the "alpha geeks". Morts may feel a sense of distance and lack of engagement due to this. Thus, they pursue other types of rewards and recognition, which may be task completion. If so, it seems logical that they value it over investing effort in design, and other technical aspects of the work, that do not contribute "directly" to creating the functionality in a visible way. They may feel that they cannot gain recognition for creating the best design for the tasks, but they can complete the tasks quickly.

 

Naturally, creating an open and positive work environment is of course necessary.

 

  Again, in order to counter this is (in addition to pursuing and maintaining humility and openness at all costs, as has been recommended forever) I believe in working with the individual and pushing them to create a vision for themselves, get aware of their ambitions and formulate a direction of where they want to go. Most often, that will be in line with where the organization wants to go. I believe very much in the drive and the passion that we all have, if awakened, if nourished -  all it takes is someone to believe in it.

At the latest AgileØresund meeting we had the usual mix of new and old people representing both devs/techleads and project managers. I (again) wanted to talk about team morale. Being a consultant I get to move between company cultures quite often, which allows me to more easily see and experience differences among them. Having worked for some of the larger traditional companies in Sweden, this is a most fascinating aspect. It is fun to reason about how the company culture has been devised and/or emerged, and what the logic behind it is - what must have been the benefits the leaders saw when promoting some values inside the organization? Morale in a team comes both from the context - from "upwards" if you like - and from within the team. A team needs a vision in order to believe in the work they do. If you do not think that the work you do will matter to anyone at all, then you are not likely to invest heavily in the work. From within the team, a breach of morale will spread: If someone looses faith in the project, that may spread and will at the least affect the others.

 

I think there is a junction where these things meet; how we express our faith and passion can become a heuristic that is then expected - a mindless rule that the team has to work overtime at some point, that the team has to do this and that. (Well, blindly following rules is almost never good, nothing new there.) This junction is basically where acting and appearances are more important than actual results. Acting and appearances are naturally very important, but are not directly related to the results.

 

Anyway, Chris mentioned this post from Kathy Sierra (I don't read her blog regularly anymore myself) that talks about the target of passion - company or work. I really see a connection to her post.

What a party it is! Even though the actual start is tomorrow and today was "just" workshops, I am already having a great time!

 

Todays highlight was definitely meeting Jim Coplien and listening to his provocative style as he recounted seven ways agile teams fail. It was all business, hard facts and no play (well, aside from the provocations and caricatures).

 

Tomorrow, I will be giving my talk on changing software with tests to back you up. It's kind of at odds with what Coplien talked about today, because I don't "care" much for the either the specification directed nor the fault directed aspects of using tests as a developer tool. I think the great benefit are the behavioral aspects. None the less, tomorrows talk will be pretty code-centric, not like my previous attempts - come check it out!

 

Speaking of the benefits of tests, we reflected on the Copliens talk on the way back in Niclas car, and missed the design and behavioral aspects: In saying that TDD is no better than code reviews (and other techniques)* I do believe that we are missing the point. It reminded me of Martin Rinard on failure oblivious computing: TDD adresses the fault-prone part of developers, I feel most older techniques lean back to the space of a more elitist view (uncompromising it seems to me). I find that it does not work, we need methods that help us with the human side of things. Most of the cases, none of the methods give us bug free software - and my take on TDD is that it neither finds faults nor guarantees behavior according to spec. It does, however, help us move forward when developing.

 

Am I too pessimistic?

 

On another note, namely speaking: I will be giving a workshop at the SPA 2007 conference in Cambridge in march, more on that later.

*I am being sloppy with the details here, it does not detract from my point, I think.

TDD offers benefits in terms of both project/work dynamics and software quality. Some benefits are obvious (feedback from tests) but most are not (small steps lead to a higher frequency feedback loop and more control). One view of this is that some benefits come as a by-product.

 

TDD / BDD (I'm going to use BDD from now on, substitute as you see fit) gives testability as by-product. This is basically the view expressed by Jungmayr.

 

The simplicity of the BDD method makes it general, flexible and adaptive. The flipside to that flexibility is that there is ample room for misunderstanding.

 

Does BDD prescribe testability? No. Indirectly, your designs *should* become testable if developed using BDD. However, there is no "step four" (after RGR) that says "review code for testability or maintenance issues and fix them". It is often not part of refactoring since testability affects design and "unit" (usually class, YMMV) functionality may indeed be altered.

 

Instead, BDD infuses many testability, maintainability and other factors of high quality software, through its focus on testing one small thing at a time, "small-scale tests", and eliminating duplication. In order to test just that one thing you must figure out a way to replace what it interacts with. You must be able to manipulate the link between them; you must make the dependency "loose". The consequence of this is that all classes will depend on each other loosely. They will not have hardwired dependencies.

 

Hardwired dependencies are when class A is coded to always use class B. This may be since it A itself creates B or uses static methods of B.

 

This makes the code less testable since there is no direct way to test a part of the system, by manipulating the dependencies. We have to use other means, via a more complex test harness, and/or tools.

 

So testability comes as an indirect result. But can we say it is a byproduct? Is it true that this is not a systematic way to get testability in our code?

 

Even though most misunderstanding is a product of ignorance, would there be a way to make TDD more explicit (in how benefits are addressed) by design? I am unsure, I agree with the idea that understanding in the form of realization is often impossible to transfer. It has to be experienced to materialise. Often, the best that can be done is offer guidance and direction, a map to where the realization of knowledge lies. The question then becomes if the benefits require such realization or can be reduced to following a systematic approach.

Short: An example of learning as the result of rotating; using techniques learnt from working with testability in new (TDD/BDD) development.

On the microlevel, we learn from inspecting the code we are creating. On the macro- or project level, we learn skills in one type of project that we can use in a project of another type. Essentially, the difference between legacy and greenfield. Working with many legacy projects, we can see the results of our mistakes, and we can see how we can work around them.

This turbocharges our learning, since the issues are magnified.

I've experienced a useful example are TDD/BDD techniques. BDD gives us insight into our software designs, it illuminates values of our designs that are very hard to find otherwise.

I think it was Pete McBreen (or maybe Alistair Cockburn) that drew the parallell to how many martial arts methods are taught, usually in several levels - the masters have apprentices that teach the novices. The novices magnify the mistakes of the apprentices. The mistakes become easy to see, the feedback is clear.

 We get this magnification when we look at code a little further on the timeline, when it has been in production for a while. The problems caused by any design decisions we made when developing make it easier to see how design affects maintainability.

For most of 2006 I have been working with projects where the challenge was in making the code testable and then adding tests. I have discovered that when I return to new development projects, many of the techniques I learned while working with existing code have helped my understanding of the BDD issues.

So for this example, if you haven't done any "refactoring old code" project, and haven't read the WELC book - I recommend doing it. There are many things you will learn from it, testability techniques not the least.

Rotation is good, both in the small and in the large.

Testability has been (for 30 years=forever in software development terms) and always will be a large factor in measuring quality in software. Bad testability = bad design. Functional requirements are definitely not the end of story on software quality (for a deeper discussion, google for software quality, McCall, Boehm, ISO 9126, etc).

 

That seemingly simple relationship is hard earned knowledge, especially among application developers. Countless comments and thoughts are a testament to that fact.

 

However, testability is not defined by if and how you use a mocking framework, or other tools. Since testability is slowly gaining more and more exposure, the way it is being exposed seems to confuse.

 

It is in the nature of many computer enthusiasts to reduce skills and knowledge to tools in the form of software.

 

Need a great picture? Easy, get photoshop. Need a better personal economy? Quicken is the answer. Want to compose music? Cubase & Co will turn you into Mozart. Right? 

 

And of course, if you need to improve quality via TDD - just get xUnit, a mock framework and you'll be a test development wizard in no time! Right?

 

Well, no. Neither testing nor BDD/TDD is not about using rhinomocks ("sorry" Ayende), just as creating music is not about Cubase ("sorry" Steinberg). Testability certainly has been around longer than NUnit...

 

In contrast, design issues such as coupling and other forms of bad dependencies are inherently bad things for testability (herr Jungmayrs dissertation puts it forward in a great way). Even more so, it is bad for software quality in general, not just testability. Again, it is something that we have "known" for decades. Even object orientation has little to do with it. Testability in the mainstream goes even further back than OO in the mainstream ("sorry" Bjarne). It has nothing to do with things like "OO purity".

 

Still, developers like shortcuts and some will fight these things every step of the way.

 

I think that the additional knowledge and competence required can be daunting, and that is why "highly OO" designs often are as bad and complex as "spaghetti code". Admittedly, even a well designed application can be hard to understand.

 

I am sorry to have to break it to some people, but whoever told you developing software would be easy, wasn't really being honest with you.

 

Seriously, "complex OO designs" are not necessary, nor required to support any xUnit framework. In some instances, you don't even have access to a framework - be it xUnit or any mock - and you just (lo and behold!) write tests as a normal app, to test your code. Which works. That means we're still not off the hook! Shucks! You still must provide decent testability and low coupling, in order to create unit tests, even though you're not using xUnit or any testing tool at all. Shoot!

 

On the use of Typemock, Lenny is right in that it is a wonderful tool for addressing the testing needs of legacy code, and that you naturally wouldn't create unit tests for a large existing codebase. NUnit provides a great testrunner. Neither requires testability to use. Neither guides us when creating code.

 

What I feel is very wrong, however, is using the capabilities provided by Typemock as an excuse to create bad quality, highly coupled and unmaintainable code. When you are starting anew, seize the opportunity! Do it right! If you've worked with getting quality up in existing code, introducing unit tests, and so on - you will appreciate the opportunity. If not, you need to rotate so that you do.

 

Typemock is a great tool and gives you alot of power. I think one should consider disallowing it in new projects, atleast until people start to get the mechanics of testing.

 

What are the downsides of Typemock? Oh, where to begin... To be continued... (picture "How the west was won" text on a grim James Arness face)

I've been educating and coaching a fair share of projects in TDD and agile practices now, and in one there was a developer that decided against the harsh discipline of TDD/BDD and agile. The reason was his love for coding away at a solution, going as far with it as he could envision (which he was very good at btw).

The principle of YAGNI has to do with focusing on current needs and satisfying only them, as prioritized by the customer and/or as is evident from the backlog (xp and scrum). It's related to the well known issue of design partitioning.

On this project, we used the term or token "golden future" to claim that we were reasoning about issues that were far from where the project was. Another term that made an entrance was "deep" coding. This is used in many places to mean locking yourself up and focusing on a problem, usually also a problem that requires the dev to go deep into the underlying technology to find a solution.

Here we meant something similar, but referred to the solution space (rather than the technology/system space): To code "deep" was to take a task / user story and develop it as far as the dev could at that point in time. A spike, if you will.

My point here is that the term has a positive ring to it, in the ears of the engineer/developer. To go deep and solve something hard requires skill and means that you are doing hard and complex work.

We would probably have been better off to choose the term to code "far" or code "away". Coding far means to wander off in one direction, hoping that it is the right one. It means to never check the map or the compass until you are feel "done" and have exhausted your vision knowledge. By then you are far out in the forest, all alone.

Are you close to your destination? Or did you just spend alot of time wandering?

(The iteration demo)

Jim Shore has put up yet another text from his upcoming book ("The Art of Agile Development") for review on his blog. This time he talks about the iteration demo: A live demonstration of what has been accomplished during the last iteration, that can be attended by anyone that is interested. Jim describes the demo as a "way to keep the momentum going" and lists three purposes to the iteration demo: (1) Demonstrating progress, (2) keeping the team honest about progress and (3) soliciting feedback from interested parties and stakeholders.

I feel that an essential benefit of the iteration demo is how it portrays progress and instills the feeling of momentum in the team. Agile development can actually suffer from the way progress is flows in tiny increments, making it difficult for developers to perceive the speed and momentum of the progress. This may make the team feel that there is little momentum and that little happens - since everything evolves so incrementally. It's like when you watch some slow movement, such as watching clouds on a calm day, trying to discern what direction they are moving in with no fixed reference point: It is not immediately apparent.

However, to someone outside the project, the progress made over one week is obvious, since (presumably) a great deal has happened since the last reference point (the last review of the product). Again, if one were to mount a camera at the sky and take pictures at longer intervals, movement would be immediately obvious.

When an outside stakeholder reviews progress, there is commonly a strong positive reaction - "wow, all of this has been created since last time? Cool!" When developers see this emotion, it is "transferred" to them - they effectively experience the feeling of momentum and progress via the reviewers of the demonstration.

The negative effect of *not* perceiving progress and the momentum of a project is great - a project that is taking great strides forward feels successful, and causes team members to be substantially more productive. The iteration demo is a device that allows a team to get that valuable feeling and productivity.

I was pleased to notice that so many had not had the opportunity to get up to speed on continuous integration before our talk yesterday. Of all the people in the auditorium only 2-3 felt they knew what all the "hoopla" is about.

Even though we could have used the full fifty minute slot, I think that we managed to cover the essence - although there is so much more there in the form of experiences and perspectives to talk about.

As promised here is the presentation slidedeck. Since it was so heavy on images I have made them smaller, although this download is still large (6mb).

Links to good articles - the web is naturally full of both good and bad, but don't miss these:

• "Continuous integration", good article by Martin Fowler.
  There is actually a new and an old version.
  
• "The agile difference for SCM" Very nice agile overview with SCM focus by Appleton et al.
  
• From some XP summaries by Don Wells (this one has some links to interesting discussions on c2 wiki) and Ron Jeffries
• "Continuous Integration – just another buzzword?", nice overview by Appleton et al
• "Codeline Merging and Locking: Continuous Updates and Two-Phased Commits" , good info on 2-p commit pattern (Brad Appleton, Steve Konieczka, Steve Berczuk, same gang as above)
• "Agile SCM - Build Management for an agile team"

On the conference:
We had a great time at Developer Summit 2006 in Kista, Stockholm. I applaud all the great guys and gals at Cornerstone for managing to create such a cozy gathering!

The first day started out with an interesting overview of mashups and the semantic web. Erik did a great top 10 developer donts kind of thing that I enjoyed very much - highlighting best practices, many of which are reexposed in agile. After lunch, Jimmy did TDD and we got a nice agile progression going upto my CI talk. The second day highlights for me was probably Manges entertaining causerie on Web 2.0 and an entertaining overview of open source development in .NET by Mats Helander. Patrik did WF and Johan a potpourri of coming VS.NET stuff.


Lets hope we get the same kind of event next year. For more conference and development fun this year, keep your eye on Öredev scheduled for November.

Agile methods focus on the people issues in developing software; the people perspective of the open source movement - ie the community - is often the perspective that is most emphasized and cherised, for good reason. People are always the focus, technology is secondary.

Rob Mensching at microsoft (who is behind MS open source - CPL - licensed WIX installer toolkit) has a very nice post about the people part of OSS.

Are all of the agile practices so new?