Sunday, February 28, 2010

Cooks & Coders part 2

Service Time

For those of you that haven't worked in kitchens full time for a few years or more or read Kitchen Confidential the similarities are striking.

In part one I went over the roles and how effective teams exhibit the same traits in different situations. Obviously it's more about jelled trusting (and trusted) teams opposed to much else.

The timing and duration might be different between the actual events of building software and a service over an evening in a restaurant, though they are mostly similar for successful teams.

As I mentioned before, I've had the pleasure of working in both successful kitchen (teams) and on software projects, in just about all roles so far (made it to 2nd chef and lead dev a few times).

Knowing what

In both of the situations I don't think (or hope in hindsight that) I ever fell prey to the conceitedness that I was "leading" either teams or situations, I was just aware of what was going on and occasionally asked people to clarify to me or them that they were OK.

As it was, we all just knew who did what, where, when, how, what was expected and how that all fitted together. Nobody was scared of failure for something they weren't responsible for, let trusted that the people who were filling the relevant roles would do so, it's why there were there.

We sorted that out before we tried to do anything, seems easy in hindsight.

Competition and the death of learning

Luckily for the most part people understood that no one person is an authority on everything, so we were all learning as we went along. The idea of competition never turned up as it would of done nothing but killed the trust and openness that allowed us to learn from each other. If I'd know I was going to "look weak" or be belittled for asking how to make a white sauce or how a particular regex worked, I wouldn't of asked and would of never learned.

Best leave that kind of attitude for sports.

Too busy to "manage"

Typically I found myself too busy doing what I was suppose to be doing in either situation to both myself by bothering other people about what they were doing, opposed to ensuring that I was OK and just trusting them. It's a hard thing to do when you "feel responsible" for what could be seen as a "failure" overall, though it isn't really and chilling out will allow the people to relax and things work out the way they should, it's what skilled happy people want to do, get it right and get it done.

Smoke break

After a busy menu writing and service prep (or even a requirements kick off and design) I always noticed in successful environments that the restaurant GM or business "suits" left the chefs to do their job.. The idea of standing in the kitchen, changing the menu and trying to pour more wine that is needed into a reduction or pasting white sauce on steak was (correctly) alien to them.

They were do busy having a smoke break knowing they had completed their task in order and now it was over to the kitchen (production engine of the company) to turn around ideas and desire into service and deliverables.

Conversely once service was done and all the food was out (software launched) most of the kitchen would be out the back having a smoke (yes I used to years ago) relaxing after a job well done, while the front of house (support staff) helped out with the new deliverables and gathered the feed back. Occasionally a chef would have to pop back into the kitchen and remake a meal, or cook a steak some more.

But that the communication & planning was taken care of up front and then allowed to be executed it was rare.

Then the front of house bring all the plates back in and the kitchen porters take over while the chefs play quake ............

I always trusted the members in those teams because we knew what each of us had to do, and we allowed (left alone) each other to do it. There was no need for threats & shouting or overtime in the kitchens/teams I was in because they were too well oiled and efficient.

As Jerry Weinburg said :

"We don't work over time to get the work done on time, as to shield ourselves from blame when the work inevitably doesn't get done on time"

Or as Shane Hastie said :

"Make yourself redundant – the leader must be able to back away from the team and know they have a concrete understanding of the goals and objectives they’re aiming to achieve and have the support they need to get the job done."

(I cut out the second half of the quote as I don't agree with that bit).

Another good read.

Do it right, enjoy it and chill out, also remember : if you're not happy doing it, do something else or do it somewhere else.

Tuesday, February 23, 2010

Changing development : Part 2

Where does it have to being

........ well every where at all levels it seems

Depending on your environment here is a very good start, a good list of behaviours but the out comes and behaviours are the same.

As that article points out you can do a strength & weakness approach and attempt to categorise things, though most like being that it's people we're ultimately talking about, it's going to be too fluid to be that black and white.

Typically I find that the true test of things (people, process, approach, engineering, relationships) which are basically complex systems is what happens when they "go wrong".

Most healthy systems will attempt to self heal and come back to kilter after being effected, a family can bond together after a loss of a member for self support, a try {} catch {} exception can be handled by an aware system, two partners can communicate after a period of conflict, etc. ....... if the system is able and allowed

Process process everywhere but not a drop to drink

It seems a fair few assumptions are made about process, basically that as long as "its there" or talked about, life can carry on as usual (resisting any change). Or in other words, as long as you pay lip service to "process" you can carry on creating as much chaos as feels good.

Guess what ....... wrong, and here's why.

Being a tool

A process is just a tool, and a social/team one at that. It is not a cure for the ills of a sick organisation, it's something that is put in place to support a way of working once that way is decided and agreed on, otherwise you'll just have the system trying to do things and defaulting to the old chaos when the new breaks down a missed equilibrium.

It's good to talk

To talk about the value of good communication would be insulting to the average reader to cover, though lets just say without that, nothing else is really relevant. It's akin to being concerned about your health or fitness, while still smoking.

If work is the changing of idea(s) into a tangible output ..... then the communication (quality of) has to be the #1 issue in the early stages.

I dare say we've all been there, getting the same piece of information from several people via email that turns into massive email storms from people "just being helpful". They are just creating work for everybody having to filter and tolerate this wonderful and particular kind of weirdness.

I remember working for a company that had a few locations (different languages & geographic locations), they had the equivalent email alias of everyone@ ..... the rational behind this being that company wide information would be sent there, announcements, info from the boss etc....... two days is all it took to have people using it for discussions about who was buying biscuits and tea.

I blocked it and encouraged others to as well.

Because when people are overloaded they shut down and things are missed.

This is chaos :)

Horse before cart

With things like this going on, any "magic process" will fail.

Who tells who what ? No process will sort that out, only people who know what they should be doing and much more importantly at the beginning what they shouldn't.

Make sure you have that taken care off before trying to get anything going, as it will just fail in a heart beat and cause more confusion, resentment and resistance that was there before you started.

As ultimately you'll just be another voice in the cacophony, though hopefully one that will recognise that things like shouting, bullying, threatening, micro managing, and being generally chaotic is a source of the issue not the solution.

So when faced with it, just do that, face it don't add to it.

Thursday, February 18, 2010

Changing development : Part 1

A rolling stone gathers no moss

Change .......... well it's either something you like, dislike, can or cannot deal with ........ so it's like most things I suppose, a fairly cyclical arrangement but always present.

Lately I've experienced a fair amount of change, and have found myself in a new position which is both a change for me and a role where I have to effect change, lots of it, near constant evolution at that.

Changing the outcome of a development process that is; but not by defining the outcome any more (using power point or buzz words or the latest "approved" process). But by effecting the manner in which things are approached (done) by people.

Bit like golf and the approach I'm guessing.

Quality software is the name of the game, not short term money ........ or more importantly, not getting called at 2am because the servers blew up or are failing under load.

Or your entire user base (or dev team) leaving as quickly as your projects flees from doing things the right way (be that out of panic, greed or not knowing how to strive for quality).

Where you are, not where you've come from

Few things annoy me, though finger pointing and blaming others are quite high on the list.

I rarely care in the moment about much of the history leading up to how a system evolved, most developers try to do the best they can in the moment, in the situation they are subjected too. Hence saying X did Y and is pointless, serves no purpose other than to add to the distraction and annoyances.

That said ........ what is actually important is being aware of what you actually have and what state it is in.

Reacting to what is thought to exist by guessing at some symptoms, will 99% of the time make it worse, I don't want to think about the number of times I've seen that one and decisions coming from "Oh I thought it was slow due to the server opposed to inefficient code."

So step 1 as a wise person once said "Don't just do something, stand there" resist the impulse to rush in a "fix" (a.k.a. mess up more) what is there.

Whatever it is, will likely be there in a short time once you've thought about it and then you can deal with it.

Where are we going

Step 2 seems to follow step 1 nicely.

Now we know where we are, we can then think about how to get to where we want to be. Simple enough, though getting people past step 1 is likely the hardest bit.

A bit of creative destruction is typically needed.

Running on broken legs is quite hard, much the same as working in chaos attempting to build anything of stability. Let alone being told to run faster or with other people who are crashing into you, when should all be helping each other.

Some tools can help, task/project tracking, version control and coding standards are a no brainier these days (I like Trac for instance, SVN, phpunderControl, phpcs, etc, ).

But just having them is nothing, that they are used and serve a useful outcome is the point.

Nothing is a standard or "accepted" until .......... well until it is, i.e. used daily, familiar, accepted and part of how things are done.

Then you can talk about having a standard or "process", until then you are experimenting or adapting the tools to the situation and desired outcome.

Learning to walk in step will seem strange to people who are used to walking around on their own, though when you have to walk with a team (let alone run) there are better ways of development teams working together.

I usually think about flocks of birds or any natural system, mother nature has put the writing on the wall in 500ft tall neon for us ....... personally I shut up, watch and listen to such patterns and complex systems that appear so simple, how do they do it ?

Just about everything we do is interacting systems, they just need a bit of tuning ;)

Hence where the cycle of development comes in, it's flat and flows between each area, idea->design->dev->stage->idea->etc ...... and so on, with what ever steps relevant to your situation.That can either be progressive or agile etc.

Guiding momentum in such a way is always fun, though once it's going and speeding up, just stand back and grease the wheels occasionally :)

Sounds like a dream ? ....... maybe for some, though not one I accept as unachievable, I've experienced and been a part of it too often.

Juggernaut development teams know what I'm talking about. Brownie points for knowing where that reference comes from.

Are we there yet ?

Good old step 3 ...... coming to terms with the fact you never get there you just succumb to continuous integration and accept a permanent state of improving the software (call it perpetual beta if you want), and that all things in life go in cycles and evolve, some bits die some get stronger, but given momentum they carry on.

Jan 2010 Magazine had a good article about Going Industrial

The actual steps I can comment on later :)

Lets build Austin Martins not Trabants people !

1. Asses the current state of development & tools before acting
2. Find out what the actual outcome the team & company want

3. Align the team the common goal
4. Get the correct tools (and process, though process is just a social tool after all)
5. Hold off "management" by explaining the process of change
6. Have the confidence to allow it to happen opposed to pushing too hard