Not Waving But …

In a (rather good) follow up to his red flag pairing post Obie Fernandez thinks I was a “unnecessarily dramatic”. Probably, but what the hell, its a Blog!

Pairing can be a hard sell to a bunch of experienced, effective and productive developers (same goes for TDD actually, but that’s another story). Throwing in “pair programming is one of the only effective ways that a lot of us have ever witnessed keeping average developers from pissing away 95% of their productivity engaging in non-work” really doesn’t help to get their respect and buy-in.

Do I really think they are just “average”? (I don’t)

Do I really think they “piss away 95% of their productivity”? (I don’t)

Do I think they could do better and have more fun and satisfaction Pairing? Yes, that’s the sell, but they are not hearing that because they are too busy seething at being implicitly labelled as average time wasters.

In his latest posting high profile Thoughtworker Obie Fernandez comments that:

“Truth is, pair programming is one of the only effective ways that a lot of us have ever witnessed keeping average developers from pissing away 95% of their productivity engaging in non-work such as reading and writing blogs, instant messaging, personal email, shopping online and otherwise wasting time on bullshit.”

…

“As far as I’m concerned, all the other benefits you get from pairing like continuous review and knowledge-sharing are just gravy.”

So now you know, All that good stuff about continuously reviewing code, helping each other stay focused, making sure everything is tested, avoiding blocks, solving problems faster and sharing knowledge across the whole team doesn’t really matter. No, pair programming is mainly a management technique that sets up average developers as Thought Police to enforce “good” behaviour. From the earlier comment I assume that “a lot of them” (other Thoughtworks Consultants?) have already tried key loggers, IP sniffing and surveillance cameras?

For the record a team will work hard if they get enough internal satisfaction from doing so. External factors such as threats, rewards or the Thought Police have been demonstrated over and over to fail. How you foster that internal satisfaction is where the “art” of management comes in.

I like Pairing, though it is a hard sell. Frankly, the sell just got harder, its a shame, because for a while there I thought Obie “got it”. I know, from working with them, that this isn’t the view of many Thoughtworks guys, I just hope that this sparks off a “robust” internal debate.

Take a desired system.

1. Break it down by desired features
2. Add the features to a Prioritised list
3. Do the most important ones
4. “Prove” you have implemented them
5. Put it into production
6. Reflect on how that went and tweak the details of how you did it

Repeat until your customer asks you to stop.

There, that’s not so hard … is it?

One of the tenets of many Agile Development approaches is that the system’s Architecture evolves over time. The claim being that the architecture will remain optimised for the systems purpose and will be easy to understand because it doesn’t have a load of hooks and parameterisations to allow for unspecified requirements. Extreme Programming has some aphorisms to emphasise this: DTSTTCPW (“Do the Simplest Thing that Could Possibly Work”) and YAGNI (”You Ain’t Gonna To Need It”) spring to mind. Martin Fowler’s article Is Design Dead is one of the classic descriptions of how it should work.

Agile developments have an imperfect memory, with little historic documentation it is reasonable to view each architectural decision as being made using the current system architecture and requirements as the only inputs. That being the case then the evolution of the architecture can be seen as a Markov Chain or Drunkard’s Walk (at least metaphorically).

What does this mean? The ideal architecture is as described above simple, and focused, it should also be balanced and not restrict you from taking it in any a particular direction. This last desirable trait is invisible, you don’t know you cannot go in a particular direction until you try to go there.

It is inevitable that each change you make to the system takes you off the ideal “balance” point for taking the architecture off in an, as yet unspecified, new direction. You might feel that as each requirement and takes you “off balance” in a random direction then the likelyhood is that, overall, you will stay on balance. This is where the drunkard’s walk comes in, over time a random walk diverges from the centre line, never to return:

Over time your architecture will become less balanced and amenable to change. Getting the balance back will probably require an architectural review of some kind and some kind of more disruptive change than another simple refactoring.

As a software developer I don’t make claims to change society, however in both software development and social engineering the actor is peturbing a complex system made up of empirical processes and that means that lessons in one area may apply to the other.

In The Open Society and its Enemies Karl Popper wrote that “the piecemeal engineer will adopt the method of searching for, and fighting against, the greatest and most urgent evil of society, rather than searching for, and fighting for, its greatest ultimate good.”

In many (most?) areas of software development the developers are implementing a continous stream of new requirements and fixes to existing or emerging problems. The process is never “finished”.

So it came as a pleasant surprise when I found the following table in Conservative Political Philosophy and the Strategy of Economic Transition, by Peter Murrel and I couldn’t resist the parallels between this and a comparison between “traditional” and “agile” software project management methods.

Characteristics of Utopian and Piecemeal Approaches to Policy

Note on empirical processes: Process control theory states that a defined process is predictable; it performs the same every time while an empirical process does not. Empirical Processes are chaotic (in the sense of being extremely sensitive to initial conditions) and effectively unrepeatable, requiring constant monitoring and frequent intervention to ensure the desired result.

I recently attended a presentation in the City of London on a high powered infrastructure component and architecture.  The attendes were the usual bunch of attendees, IT guys at the geekier end of middling to senior management, early adopters of various technologies.

During one of the sessions the presenter was explaining how this technology could enable Service oriented architectures:

“I guess most of you are implmenting SOA now.  In fact, how many of you are implementing SOA right now?”

Of the forty attendees one hand was tentatively raised.

For me the crucial difference differentiator of an Agile approach is the obsessive desire for feedback. Basically, if your reaction to an issue is to work out how you can get more, objective feedback faster then you are going towards the agile end of the spectrum; if it isn’t you are not.I will go out on a limb and suggest that the vast majority of system development failures are due to the lack of feedback at various phases of the development process.

This isn’t a new thought, it is as old as Kent Beck’s driving story from the earliest days of XP. It does get lost in all the talk of principles’ and ‘practices’ and ‘levels’ though.

After my dalliance with Typo I am back on Wordpress.  I found I was spending too much time fiddling with Typo and not enough time writing (and the fact thta my half assed configuration just stopped working with monotonous regularitywas discouraging).

So here I am back on Wordpress.  It was a manual migration so it looks like I wrote a bunch of stuff today.

Lets see if I manage to spout off a little more now eh?

Listening to a development discussion today I was struck by a thought on optimisation. We don’t just optimise software (for speed, size etc), we also optimise it for rate of change. In fact optimisation for improved rate of change is one of the fundamental contributions of the agile movement. After all refactoring , DRY, OAOO are not necessary if you never change your code (well, that’s not strictly true but it is enough of a truth for now). The discussion I was evesdropping on was about building a simple framework verses writing targeted code and I found myself rooting for the targetted code. At another time in the day a different group of developers were arguing about the whether to refactor some code they had just written or not. In both cases I felt that the arguments for refactoring now “It will be easier to change” and the arguments for the framework “it will be easier to incorporate new projects”, while factually true were not winning me over. The point was that the framework and the refactoring were optimising the ability of future developers to change the code. In each case the arguments were not winning me over because I didn’t think those areas would change much in the near future and the changes did add complexity (if only by adding a bit more indirection). So, the arguments were for a premature optimisation of the malleability of the codebase. Now we all know about premature optimisation, but I’m not sure we always think about it in the context of our process, rather than the codebase. So the next time someone want’s to improve the codebase “so it will be easier to change”, wait until you know what the change will be. You never know your luck, you might wait forever.

Well, Here I am on Typo. Still finding my way around and working out the details. I think I am going to have to learn one of the markups soon.