perspective programming

Team Balance

There’s a lot to be said for flexible work hours. They’re all the rage but they can be tricky when you need to collaborate on something meaningful. Maturing teams understand this and introduce “core” hours. That is, everyone -must- be in the same space for a set number of hours during the day; you get some flexibility to decide where to put the rest: on the head, or the the tail of that day. And then you have overtime….

An experienced team will undervalue overtime. The productivity gains are superficial and short-lived. The latent bugs and burnout issues which crop up down the line are way harder to solve. And that realisation, unfortunately, takes experience. Sometimes, more than you need. And sometimes, even when you have that experience, you doom yourself to repeat the same mistake under the illusion of end-of-the-world-pressure. But it’s not just the team you need to look out for; it’s also the individual within a greater team…

The output of any team is not merely the sum of individual contributions. It’s a collective output which is the combination of a number of quantifiable, but difficult-to-measure, actions: hallway conversations, peer pressure dynamics, inter-personal relationships, email:work ratios, extra-office activities… and on and on. For the most part though, a team result requires that the team move together at the same pace. Which is why they can either be really funky, or really frustrating, depending on your own personality.

So when you have one individual burning faster and more than the average pace of the team, you need to be cautious. Yes, leaders will put in more than normal: that’s what gives the team acceleration; impetus; momentum; drive. You have to start somewhere, sometime. But at some point, everybody should work roughly at the same pace. I.e. given a particular skillset and competence, the task should be completed by two different individuals on the team within the same business delivery time frame.

What happens when one cog spins more than the rest? For a start, that project plan (which you mostly ignore) gets even more muddled. The expectation for delivery timeframe changes (not just for current workload, but for future reference too). The inter-personal dynamics change (competition). The path of least resistance shifts and the workload tips in favour of the “Doer of More”. The rest slack off and you have this horrible elastic stretch in your execution plan. It will snap. 75% of the time. The other 25% of the time, it also snaps.

Now, you have to stretch that elastic from time to time. A balanced and measured test of that is a good thing. Shake things up and stir the pot. It’s healthy if controlled properly. Sometimes you get an unexpected organic boost of productivity which shifts everything into a neater gear: run with it. Recognise that and facilitate it. But don’t let it run out of steam “naturally”. The human spirit is strong: just watch the finish to any massive endurance test. People will push themselves beyond what’s probable and into a state of “cannot-do-anything-for-3-weeks-until-I-am-recovered”. So unless that’s what you want to achieve, nip it in the bud. And that takes a skilled project leader.

But as a peer, you are more intimately aware of when the pace changes. You have a responsibility to highlight that and bring transparency through to the fore. That’s what standups are for, right? Talking about the technical hurdles and objective progress of a project is EASY. You can go through 100 standups without challenging yourself or anybody else. Another path of least resistance. So how about using standups to bring attention to more important matters- issues that bug you in the soul but are hard to talk about?

Again, a good leader will cut short any ad-hominem or diatribe and schedule a time and space for it to be dealt with properly. The nice thing about using the standup for that is that you have the opportunity every day to voice your concerns. You even get to sleep on it for one night, to shift your ego away from the team’s greater good, before raising it.

Balance is not something we can always achieve on our own; despite our ingrained philosophies. That’s where East and West are remarkably similar. Both focus on the individual achieving his/her own internal balance and striving for that. But there’s nothing like pitching in and helping each other achieve balance.

You’re not walking on that tightrope alone. And yes, you work hard at making sure you’re not the one that causes the fall. But help others at the same time. In the wise words of Oogway: “One often meets his destiny on the road he takes to avoid it”

perspective Technology

HOWTO: Adopt Agile

I’ve heard the stories, read the reports, discussed and debated, disagreed and agreed, worked together and against each other; i think there may even have been blood spilled at one stage? I vaguely remember something about a keyboard and a dwarf… Indeed, if there ever was a word in the software industry which could raise the room temperature, it’s the little word “agile”.

HINT: If you ever find yourself listening to a techie and he/she/it is boring you with details from another universe and you don’t have a clue as to what they’re talking about (or what language they’re using even if it does sound remarkably close to your mother tongue), just randomly blurt “Agile!”- then stand back or run.

One of the concepts in agile is iterative development because iterative processes help achieve a goal efficiently by giving you the flexibility to change your trajectory as the goal itself moves. If you’re aiming at a goal that never moves, then this story is not for you. Also, check your goal for a pulse- it might be dead. Hence, it makes ironic sense to adopt agile in the same manner: iteratively. That is assuming you want to adopt it at all because if you don’t then there’s no point in proceeding any further. There are none so deaf and blind is how i remember the expression…

And the processes, practices and insights that agile opens us up to- testing, refactoring, pairing, reviews, continuous integration, dry, yagni and company- are also metaphors for adopting the very process itself. And even deeper, the metaphor for every software project should also be embraced for setting up your own company’s adoption of agile. Can you feel the power of recursion starting to make your head throb?

So think of adopting agile as a software project on its own and take it from there. Create stories like “get Paul* to integrate more than once a day consistently”. Get team players to estimate on the story. The team players in this case are those who actually want to get agile ticking along (volunteers). So it’ll probably take 2 weeks before Paul gets it right. Maybe if Igor* took the story he could “convince” Paul inside a week? Create your storyboard, organise the flow, derive a project plan, split it up into more iterations (if need be)- the usual. Then “code”.

Having trouble with Paul? Pair-up with someone. Tag-team it. Refactor. Check in your working “code” regularly. Review what’s been done. Write new stories. WARNING: You might actually start having fun. Role-playing is an essential survival trait of almost every developer. It’s addictive and to pretend that you’re actually the software is going to be a little mental for some, a little esoteric for others but hysterical for a geek. Oh, and don’t be surprised if your developers start to get a little carried away and come dressed as hexadecimal numbers to work. Just keep a straight face and say “Ah. Good morning, 1.6A09E667”.

On the serious flipside, when you start to setup a project plan for adopting agile in this manner you also get to eat your own 0xbaadf00d; practise agile more; refine valuable skills; learn lessons; incorporate it into team culture; get an empirical idea of how close you are to hitting the mark and have a working team at all times (this is most serious). All the feel good fluffy things you want to hear.

And on the negative, less fluffy, pessimistic , dark and evil side of things, when you start to overrun your estimates badly on a lot of stories, you also start to get some really good feedback on when to can the adoption and/or start again or try a new tact. Ok- that’s actually good news too. But how much you try will depend on the strength of the character flaws in your project leader.

And before you know it, you’ll be miles away from being the perfect agile team. Indeed, just like software, there’s always one more feature you can add or take away. There’s always that one routine that can be a little better. And over time, you need to make changes that help you stay relevant and marketable and profitable. It’ll always be perfectly imperfect. And so you keep coding, creating and evolving something even more beautiful (and useful) than you ever imagined in your wildest electric dreams.


HOWTO Do Software

The expression “software is hard” (a quote from Donald Knuth if I’m not mistaken) has seen a lot of mileage (yours truly contributing my fair share) over the years because of it’s simple truth. And in that, we’ve all searched and found (or not) some or other holy grail of methodology. And then the methodology wars began…

And with each new spin, a new skirmish emerged on the radar. Even some of the the tool-chain manufacturers got involved, either creating their own style or methodology (i suspect largely to suit their product rather than the process) or adopting their product to try and encompass the latest and greatest in fashionable methodology. Much ado.

Now software is both art and science. And as such, you need a healthy dose of both to get it right. The art demands your imagination and creative skills; the application of your emotional quotient and your ability to think beyond the four-sided. The science demands much the same plus discipline. Art, too, demands discipline (find me a great writer, painter, cartoonist, graffiti-artist, musician who did NOT practise and hone his/her ability each and every day- for hours each day). Art and science are much the same. Discipline is but one of the common threads.

Discipline to sit down each and every day, for hours, and get it right- get it perfect. That doesn’t mean just hours of random throwing paint at the canvas or the random plucking of guitar strings (which is my forte, by the by). And what about the scientist? Does she spend hours each day in the laboratory throwing random chemicals together into a test-tube to see what might happen? Maybe once in a while, that kind of activity is fun- but not a primary activity.

No. They all set themselves down each day, both scientist and artist, and constructively engage their brains, and think for themselves about what they are actually doing- or going to do. They know before the experiment or song or painting is completed- what to more or less expect. Sometimes it doesn’t turn out that way- and the results are either surprising or horrendous. Sound familiar? But by and large, it’s predictable- and it should be. Software is no different.

How you get there, and which methodology you use is largely irrelevant (i say largely, but you need to read the legal copy disclaimers in fine print carefully); as long as you have discipline. Following a set pattern so often that it becomes part of your autonomic nervous system is key. There’s good reason to do it, especially when you add in the one thing that distinguishes software: deadlines. Although, I am sure that in this day and age, professional artists and scientists suffer the same. Deadlines make the job more interesting- and the need for discipline even more critical.

A brief observation of any professional field where life and death are important will reveal the stand-out-in-your-face notion of REPEAT. In fact, it’s the only way we actually ever learn anything. You repeat the excercise over and over again (ad nauseum some might say) until you get it right blindfold. Why? Because when there’s a deadline, you go blind. And the more impossible the deadline, the more blind you become. You don’t have time to think- just time to do. And you need to make sure you are STILL doing it perfectly.

So, HOWTO Do Software. Pick a way. Find a way. Develop a style and method of delivery that embodies rational scientific reason to justify the “why” you do it that way. Don’t do something or end up doing something “just because it’s the way we do it” and not have a valid reason and purpose behind the behaviour (and I’m afraid if you don’t even recognise that, your opinionated delivery is just going to be that- opinionated). Add in your own artistic flair- but above all- be disciplined about it. Not just off beat, whacky, eccentric, random or out there. Notice i said “just”. Which means you can still be off beat, whacky, eccentric, random or out there- just be disciplined about it. Oh- and write quality tests 😉

Rants Technology


Much has been said about quality of software, and even more attention has been given to it. Further, a lot of methodology, and general how-to-do-stuff from project management to code implementation, even design and testing is focused on quality, including the ubiquitous “best practices” and framework collections out there. But then it struck me. All the software i “actually” work with is buggy.

It’s good enough, get’s the job done and i live with it, mostly. And like any good web-theme, the software will be replaced (read: recycled) soon enough, so why the big fuss about quality anyway?

If you got a good idea, get it out, sort the bugs out later, and if your idea is any good, you’ll break even before you manage to iron out most your major bugs, by which time it won’t really matter anyways. Uhuh, i hear a lot of “but that won’t work with real business software”. Really?

How many projects you code, pick up, migrate, port, patch, fix, debug or rewrite because business was complaining that they were (now) “too buggy”? But they were using them, right? And probably surviving pretty well with the “broken software” since now they can afford a software team to code, pick up, migrate, port, patch, fix, debug or rewrite. And the job would be done “ok” except that now, quality is an issue.

Reactionary management has a lot to do with it, but it leads astray and breeds a buzz which forges a plethora of blogging on delivery quality, all under the guise and good name of “it’s what the customer wants”- which they do. But not actually :p

When last did you use bug-free software to pay the rent?

Disclaimer: naturally, this is not a call to “down with quality”, or even “forget about tests”. it’s just a very radical and extreme (for me, at any rate) reflection on the focus we give to quality. For one, i groove on quality 🙂 while at the same time i can secretly admire that *some* manage to manage buggy software better than they can actually write it 😀

Business Technology

Enforcing DDD

So you’re all excited about TDD by now. You’ve also hooked into DDD and cutting your teeth on some of the more progressive methods for delivering software accurately, and, fairly rapidly. And with time, you probably need to start leading a team in DDD. Or you just need to interface with a team but want to make sure everyone’s on the same page. That is, the last thing you need is DDD-mutiny…. 🙂

We were putting the domain together and started adding in the NHibernate mapping files. One of the many beautiful things about NH is the ability to generate the schema based on the mapping file data. Now, strictly speaking, the database is not all that important from a design perspective. At least, that is, not initially if you try remain true to your DDD-allegiance. Anyway, this post is not about all that. This post is about enforcing DDD and one of the things you might want to do is remove the temptation to do some fundamental ERD analysis during the domain design. And if you don’t want to, then don’t 🙂

So how’s this for aggressive and extreme?

<?xml version="1.0" encoding="utf-8" ?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">

    <class name="NHibernate.Examples.QuickStart.User, NHibernate.Examples" table="[2239987-9382WED-23D23]">

        <id name="Id" column="[LKJDSA-98DSJHDS-9D76SD]" type="String" length="20">

            <generator class="assigned" />


        <property name="UserName" column="[130SF98-08JDY-98BNXDS]" type="String" length="40"/>

        <property name="Password" column="[10DDD398-08EFHJDY-98CVBDDS]" type="String" length="20"/>

        <property name="EmailAddress" column="[1098-0KHS8JDY-98DDDS]" type="String" length="40"/>

        <property name="LastLogon" column="[10998HG-08JDY-98DS]" type="DateTime"/>



You get the idea? And replace those funny column/table names with GUIDs for extra spice. Or even better, random base64-encoded strings. Of course, you can write a script to generate random table and column names for all your mapping files in a release build if you’re not comfortable with the idea of a “random” database schema during development.

Imagine trying to decipher the following while debugging:
select KJHDSA-AS878, SL-983LD23-2J FROM ASLKAJS8-32JH INNER JOIN ASLOE-876-35 ON DAS-3FE-43 = 321JDH-8786 WHERE ALOYWI-9876D = 2

For me, the bigger question would be: why are you trying to debug the SQL when you’re effectively abstracting that part of the solution and ‘supposed’ to be treating it like a black box?

But before anyone gets me (too) wrong, I’m not suggesting this as a standard practice, just a far-out idea which opens up some possibilities for managing DDD adoption 🙂

Perception of Control

one of the biggest challenges facing any lead position [particularly in an agile domain, but not solely within that domain] is wrestling for control. the processes, frameworks, tools and values are established in order that some kind of control may be exerted over the chaos. and in a position where you are required to lead, you are perceived as controlling, to a greater or lesser degree, those systems. a kind of lion tamer, if you will. the tricky bit though is not to buy into the perspective that you are controlling anything. once you do bite, settle in for a fight. how so?

you have a great architecture all planned [or semi-planned]. you’ve been collaborating on it for some time and you [your team visionaries] release it for implementation. inevitably, it doesn’t go strictly according to plan. and that’s ok, as long as what does get implemented is not a deadly wound, right? likewise, you have an iteration all neatly planned, but once it gets started Mr. Murphy makes his appearance. and suddenly you need to deal with unplanned, _urgent_ stories. from requirements gathering to release, when you are tasked with leading any of the above, it’s _hard_ to control it. and depending on your personality, ethics, team-size, professionalism, culture, your reaction will fall somewhere between the extremes of HeartAttack and Whatever. Or for the more detailed, see The Stress Continuum.btw, this also applies to any lead position in commerce. any business manager, CEO, financial director- they can all fall into the same trap. my disclaimer here is that i am nowhere near close to any sort of expert in commerce, but i have seen remarkably similar behaviour where the issue of control is concerned.

now control is very difficult to get right because of the linear mindset we have engrained. inputs and outputs, objectives and outcomes, incentives and goals; all work well. defining them is cognitively sound, striving for them is rational, even good. getting to them is difficult. and it almost seems that the moment we think have control of the system, we lose it. we use terms like “hit a bump, snag or hitch”. we may even resort to phrases like “sabotaged” or “hijacked”. but that perception of losing control is more likely a result of something completely ordinary. ie, not always an intentful diabolical plot to thwart your efforts. even if paranoia is a virtue 🙂

and why the linear midset does not work is because we are not strictly dealing with a linear system in anything that we collaborate on. life is not linear. yes, we’d love to ignore the impact of home on work and vice-versa. it’s just not realistic. yes, we’d love to tell people to leave their problems at home, and vice-versa. you’re blinded. and don’t let something like a terrorism impact on this delivery. when you come to work, you work. you leave all that behind, right? mmm…. of course, we do recognise major events. particulalry, the ones close to home. and there’s also good reason why we simply can’t factor all those things in to our planning. it’s just too much. we’d never get started with anything. and we also have to draw lines about what we can _allow_ to affect us, for the sake of moving along. but truth be told, things completely unbeknown to us wrestle against our perceived control of any system.

so how to combat this? abandon your perceived control. recognise you have no real control and focus on influencing the system. a leader, and we can look to world leaders here for examples, doesn’t control a nation, or even group. the ones that do we recognise as cults. great leaders influence. and since this is not about morals, but about successfully achieving, we can ignore the good and bad when it comes to using the word “great”. if you can but exert the right type and amount of influence, you will probably achieve far more than when you try control.

architecture. don’t try and control it. influence your team to get it right. that involves education, imparting values and a lot of rhetoric. process, agile or not. don’t control it, again, influence it. gathering requirements and planning the iteration likewise requires a lot of influence to get it right. how do you stop unplanned, _urgent_ stories from distracting your attention 2 days into an interation? you can not control it. but if you have influenced your sales team and product managers correctly, they’re less likely to interrupt. but that’s not to say they won’t ever do it 🙂 how do control a junior developer from not writing tests? you can’t. but you can influence them to. and so every situation you’re faced with when leading something is never about control. if you think your job is to control it, you’re more likely to be frustrated than not.

so leading any position where control is perceived, your first task in accepting the role is to recognise that you have no control. even if others expect you to. there too, you can influence expectations to a greater understanding that life is non-linear. we don’t live in a box. we don’t achieve outputs based on linear inputs. there’s too much beyond our control [and influence] to even try cater for, so we don’t. yet, in some way, we do try cater. just differently to what we might expect would work.


it’s been a looong break {and good}, but getting back into the stream, one toe at a time. And as i venture forth into what is commonly known as the “new?” year, i keep coming up against this theme of “institutionalisation”. It’s almost tangible in every domain, which is no surprise, since it takes place at our begging. In fact, more than begging for it, we expend a large amount of effort to reach an acceptable level of “institutionalisation”. labours more on the concept than i wish to for the purposes of this post, but does provide some interesting insight. In particular, “individuals who work within large established organisations can become socialised into organizational values and norms, and values and norms may become institutionalized”. Many companies actively strive to achieve this kind of congruence throughout their organisation at some level, since it will apparently promotes productivity through shared ideals, like-mindedness and co-operativity. Not to mention all the fluffy feel good factors which enable people just to work together in harmony. But does it reach a point where it becomes bad?

Neutrally, institutionalisation is just the embedding of those values. Negatively, it is the impact which that embedding has on the individual’s ability to function outside the structured environment. Positively, it is the culmination of effort in bringing people of varied personalities together such that they might work happily side-by-side.

Religion, politics, sportsfans- any social setting actually- all display some degree of institutionalisation. The extremes within each social environment tend to display the highest degree of institutionalisation, but only as a trend. Even groups which try and balance the extremes, if they play that game for too long and hard, achieve a level of institutionalisation in which they cannot operate within any extreme environment- if only for a season. Is that really so bad?

Then we look at the values embedded into our processes, our commercial ambitions, our societal goals and ideologies and how we champion them. We look at who champions them. Why do we support them? At what point do we stop supporting them? Do we champion something ourselves and why? And when we start scratching, we realise we want to achieve some sort of institutionalisation somewhere, but ironically, with really good intentions. [Ethics and morals aside, even if you’re downright evil, you’ll believe your intentions to be good] So, if we start something out with “good” intentions, can it really become bad?

The answer to that depends on many things i guess- again, more than i need to delve into. Let’s assume then that some people are happy to say “yes” and some people, happy with “no” and that some of their reasons and assumptions are valid. And some of them displaying clear characteristics as a result of institutionalisation. And some are happy to agree to disagree while others not. Sounds rather innocuous, doesn’t it?

But it’s exactly that boring mix of responses which we need to embed ourselves in. We need to be prepared from time to time to say both “yes” and “no”. We need to keep challenging the kind of institutionalisation we’re headed toward, without buying into it while at the same time believing it with all your heart and pushing into it 🙂 Shucks, half my brain just went on strike!

So, how exactly do we achieve that… ?

::shrug:: i think we just do, at least some of us do. From marriage, to social group, to local church, to sports club, to company, to development process- where ever you got people doing something together, you need to radically push to entrench the values and norms you believe in, all the while challenging them every step of the way. I don’t know of an easier way. But then again, it’s not supposed ot be “easy”, yet .. strangely .. it can be.

Agile Manifesto

It was about time for me…

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Manifesto

Owning Your Continous Integration

The ideas here is to “own” your continous integration process and make it work for you. Afterall, you spent some time setting up CruiseControl.Net and it’s ticking along nicely. At some stage, you need to make it “yours” and let it reflect your needs in terms of your process and record build data that you use [need] to make decisions.

In fact, i’d encourage you to really push into making it your own. Not just the look ‘n feel- but the real nitty gritty. Define and extend and experiment with your continuous integration process to make it add value…

the Scenario
Our automated build process runs a series of tests against a database. Before we start the tests, we need to record some information about the database; this being gathered by means of a stored procedure. We also need to persist the results as part of the build so we can monitor trends.

the Tools
* Nant build script
* Nant custom user task
* stored procedure
* xslt template
* config files

The Nant build script is included as part of the build process kickstarted by the configured in cc. For more information on setting up, review the documentation that comes as part of the distribution. The ccnet.config file should include a nant <node> under tasks, similar to this…


The Nant build script then calls a Nant custom user task which has the responsibility of executing the stored procedure and formatting the results into an xml file. To execute the custom task, somewhere along your build path, you will include something like…

<project name="ccnetLaunch" default="go">
<target name="go">
<loadtasks assembly="${nant::get-base-directory()}/mytask.dll" />
<myTask ConnectionString="MY_CONNECTION_STRING" SqlStatement="sp_myTask"
LogFile="myTask.xml" />

<loadtasks/> helps define <myTask/> which is built into an assembly and in this case, placed into the nant/bin directory. The nant custom user task is straightforward and the nant distribution includes a basic template sample which you can follow easily enough. another sample here

The xml output file itself is then merged into the cc build report. Again, your ccnet.config file handles this easily with…

<xmllogger />

Finally, you need to add the xslt which transforms the xml output into the dashboard. Add the xslt file to the webdashboard xslt folder and append to the dashboard.config file, something similar to this…

<xslReportBuildPlugin description="My Results" actionName="MyDataReport" xslFileName="xsl\mytask.xsl" />

Now each build successfully calls your custom user task, saves the result of the stored procedure to an xml file which is merged into the build output and accessible from the dashboard for as long as you got build logs 🙂

Following this concept should give you an idea of how to start owning your process and not just going with the stock standard install. Set it up, take some risks and call it your own.

Productivity Metrics

There is one way to define output for a programming team that does work. And that’s to look at the impact of the team’s software on the business.

Nothing like common sense to clear the air 🙂 The fuzziness sets in however, when we try to gauge what that impact will look like before it is an impact. So we [everyone involved in software production] have tried a number of ways to refine the one metric [or group of metrics] that we can rely on to give us a reliable clue ahead of time.

Mr Shore has posted his take, and refers to the Poppendiecks and Fowler for their perspectives. In addition, there are a dozen or so prescribed metrics that have been suggested, with varying degrees of intensity, by the handful of established agilities. Amongst all of them, my favourite and most accurate has got to be: “commits per week” [CPW].

A commit, in the way my team understands it, is the smallest change you can make to the codebase without breaking it. That’s it. It can be one story, two stories or only half a story. It can be a bug fix or a refactoring. Either way, it’s a productive change because whatever gets committed is, by principle, designed to improve the codebase.

Why this is such a good metric is because it is hard to jimmy and it is wonderfully self-regulating. In light of a team environment, the metric is also straightforward and honest in its interpretation. Most productivity metrics usually fail because there’s always *another* way to interpret it and it is loaded with ambiguity which can be used negatively; especially when the going gets rough or political.

Off the bat, if that’s a motive [ammunition] for even using a metric, or if that kind of temptation is too great- then no metric is ever going to work fairly. That being said…

Why you can’t jimmy a CPW
Wether you bloat your code, starve your code, design badly, over engineer, don’t design at all, there’s only *so* long you can work with something before you need to “offload” it. By offloading, i mean, add it to the codebase so you can work on the next part of it. In a team environment [more than one developer], the longer you wait, the more painful your commit is going to be [merges and out of date logic]. The more painful your commit, the longer it takes to commit, the more trouble you start running into. Now when everyone else in your team is committing n times a day, and you’re only contributing n/2, your siren should start wailing. The team as a whole is not productive. If you try to compensate for a bad CPW number and try make multiple commits of very little consequence, you’ve got to sit in front of a test harness for most your day watching for green or risk breaking the build, which disqualifies the commit anyway. As a result, you end up getting less work done which impacts on your estimates and delivery time anyway.

For each team, the average CPW number will vary depending on the type of work being done. For example, a spike mode will cut down CPW but the CPW number for the spike team should be the same. And it is important to realise that CPW will fluctuate, peak and fall and that you cannot aim for an “average”. Not to say that you cannot maintain an “average” for a length of time if you’re into a long predictable season of development.

As with most numbers, the actual value of a CPW holds more of an academic interest, but the values compared as trends are highly indicative of production. For example, over a period of +220000 changes to the code base, our average CPW per resource [be that a pair or individual] is 20. That’s 4x per day at roughly one commit every 100minutes. Interesting. But to make that a rule for each iteration and make the number a performance indicator over every iteration to “make the target” is just ludicrous.

I’m all for metrics being utilised to measure and estimate business return on investment- it’s part of being accurately successful- but tempered against the temptation to be blind. The knee-jerk response is not to use any metrics for fear of being misrepresented. And there are some rather “extreme programmers” 😉 supporting this position. Don’t measure because you can’t measure. That kind of thinking can also seriously limit your potential.

So either extreme position on the use of metrics is snake magic and has no place in a team committed to beautiful programming. They’re useful, everybody uses them and there are plenty to choose from. Keeping track of them, and in particular CPW, tempered with some common sense, can give you some very early indicators of what kind of impact your team is going to have before it gets called an impact.