Posts

Showing posts from February, 2010

Cooks & Coders part 2

Image
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 c

Changing development : Part 2

Image
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

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 flee