Tag: opinion

Categories
Business Technology

Overdone

Following up on the theme of overtime, voluntary or otherwise, there’s another good reason why it’s counter-productive. In a team environment, all it takes is one person to work that little extra bit on a regular basis, and because everyone’s capacity is inter-dependant, that extra workload starts to catch up and takes it toll.

For example, imagine a business manager getting more leads than hours in the day to follow up on.

Developers producing more code than hours available to test.

Testers reporting more bugs than hours available to fix.

Analysts churning out more requirements than there are hours to spec.

Might not be such a bad situation, but one of two things end up happening. Everyone catches up at an unnatural pace, or the pace-setter gets bored or frustrated because the feedback cycle is taking too long- for them.

Estimates become unreliable, planning ends up hazardous, at best, and a false sense of productivity starts to pervade the project. But it’s not all gloom and counter-productive. It only really becomes an issue when the feedback gap gets too wide. And that’s where methinks the heart of most productivity, and certainly learning issues lie: the length of the feedback cycle. But that is a book on it’s own 😉

What to do… what to do…?

I just couldn’t resist 😀 Had to log into Windows today and on startup was presented with this dialog:

randomdialog.png

What do you do?

It’s Never About The Process

Ever. Yet it’s so very important at the same time.

We drive processes quite hard, with good reason and positive intent. The process facilitates the change we desire and fosters an environment of learning with the goal of eliminating pain. Not a headache type pain (although it could be) but an organisational pain. And so in our pursuit to make things better, we create or adopt a process to either get us, or keep us, on course. But it’s not about the process and this is where i believe we have to be careful…

It’s too easy to get sucked into promoting or defending the process, above all else. And by process i am largely referring to the processes we use to deliver software. But this pervades far more than the engineering domain since it’s a social problem at the core and thus applicable to any socially organised group. It’s supposed to be all about the people, afterall it’s what sparked off the process in the first place. So throughout the process, the thing what’s most important is how the people, who are supposed to be positively impacted, respond. And to always keep in mind the difference between who they are and where they are.

And this is the part where English is a bit inadequate. In other Latin languages, there is a distinction in the verb “to be” that highlights the difference between the eternal and the temporal. It’s why you can never say in Spanish, as an example: I am hungry. You can never be hungry, you can only have a hunger. Moreover, there is a difference between being a programmer, and being a programmer. The simplest way i understand the difference is that being a programmer means it’s a calling, whereas being a programmer means that is your day job while in essence you’re really a bass guitarist who needs to pay the bills. In English it’s the same sentence: I am a programmer. And that’s the shortcoming in the verb “to be”. The consequence of which, methinks, is that we don’t distinguish often enough between the eternal and the temporal in our speech and leave ourselves open to interpretation, and more, blind ourselves in our ambitions.

While monitoring the process, and the way the people are responding to the process, we need to understand the difference between who they are as people in the eternal sense and who they are as people responding to change. What is more important in a social setting, is who they are in an eternal sense. This is the foundation for relationship, team work and ultimately, success in achieving the goal of the collective. Who they are as people responding to change is another dynamic. The former is more often fuzzy criteria for selecting team players, the latter for eliminating team players. And this is where the process fails: when selected team players are eliminated because they aren’t perceived as having integrated successfully enough into the process we establish. We choose process over people.

And at the same time, the process is super important. You cannot choose people over the process either since without the process, it would be hard to achieve anything, no matter how talented. And the subtle trigger lies in attitude. Let’s take the Agile Manifesto as an example. We value individuals and interactions over processes and tools. That is an attitude you need to manifest, not simply a great idea. And a time will come when the individuals and interactions (that are valued so highly) will sorely challenge the processes and tools: which you choose, if you choose, and the sum response to that crisis will define just how great an idea that really is 😉

Overtime

the “O” word popped up today and i can recall reacting rather negatively to the concept. having recognised my emotional response :), i’m trying to gather my thoughts so i can examine the role of overtime in a production environment with reasonable judgement. and in scanning through many articles, my reaction is more accurately against planned overtime, than overtime in general.

Indeed, when a project starts planning for overtime consciously, there are bigger issues that will lead to some demise, sooner or later. Something’s always gotta give. An interesting extension to this concept is subconsciously, or even unconsciously, planned overtime.

Subconscious planning is probably based on a mix of the following [and not limited to this list]:

  • good intentions
  • a desire to please
  • ego and pride
  • manipulative characters
  • messiah-complex
  • politics

You’re subconsciously factoring in a hero-effort *somewhere* along the lines, and you know it. Maybe you’re just not stopping for long enough to be upfront about it? You have the experience, you know about chaos, and you really should be more accurate by now. But you override sound reason. And that’s where unconsciously planned overtime differs. You didn’t know at all that what you were planning would involve a super hero push to try and rectify the quickly deteriorating project. Basically, inexperience in the domain you’re managing.

And i guess that’s how software got it’s reputation for being so overtime-driven. Unconscious planning in the early days was due to not knowing just how hard software [your project] really can be. But we’ve learned that and moved on from there. We have the statistics and collective experiences of many to testify: overtime kills. So, today, if you’re putting in overtime, you got to ask: what kind of planned overtime are you dealing with?

Of course, there’s always gonna be unplanned overtime. Power failures, natural disasters, trauma, sudden massive economic instability and similar left-field events are not usually factored into _any_ project. But they also don’t occur every day, or every week, even every month. These are rare occassions. Not your run-of-the-mill experiences that justify a demand for working overtime.

So where does overtime fit in, apart from natural disasters? For me, it would be when the team decides they want to do something _extra special_. Something out of the ordinary to take advantage of a window of opportunity or close a critical gap. And if your software is always full of critical gaps… 🙂 need i say more? It’s that extra burst of special energy that contributes significant value, and therefore requires that extra special commitment.

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.

Simplest Thing

An *agile-biased* blog would just not be complete with at least *one* article on TheSimplestThing… so here goes:

I has occurred to me [and no doubt, countless others] that after all that has been said about TheSimplestThing; there is no simple definition. The irony does not escape my sometimes blindingly slow wit, but simply put, simplest thing has not [yet] been defined with the simplest definition that can be agreed on. If simply defining a concept is not clear, how can it even be implemented?

Fortunately it seems that TheSimplestThing technicality is mostly a debate of semantic correctness but when pursued it becomes a philosophical fisticuff. You can start by asserting TheSimplestThing is X and find yourself arguing, moments later, that Such-And-Such is not TheSimplestThing because it isn’t Y.

In an attempt to capture the essence of TheSimplestThing, we use:
a) dictionary definitions
b) authoritative quotes
c) classic one-liners
d) Occam’s Razor

The dictionary definitions are the most controversial because they mix complexity and complicated [and in fact use them as direct synonyms] in order to define what is simple: ie. that which is not complex/complicated. In software, however, complicated and complex have very distinct meanings.

In fact, the two can never be used synonymously because their differences are big enough to create more potential chaos than a power-crazy nuclear arms dealer on crack. So, we can choose our words carefully with these two, unless we agree to use them synonymously but then to be specific about which one we are talking about. Or just keep the definitions distinct: surely that’s the simplest thing? 😉

Personally, i maintain that TheSimplestThing is a bit of misnomer- a red-herring- a goose chase- a magic mushroom. I prefer TheLeastComplicatedThing. That way, the solution can still be intuitively *complex* [if need be becos, well, the requirement is complex] but at least, and most important, simply understood.

Further Reading:
Simple Ain’t Easy
A Field Guide To Simplicity
complex vs complicated, + xaos
No ! Your software is complicated, not complex.