" /> What I thought yesterday...: July 2004 Archives

« June 2004 | Main | August 2004 »

July 22, 2004

New scanner - Epson 4870


This is a full 6x6 cm negative scanned on the Epson 4870 scanner I bought a couple of days ago. I think that I made the scan a little dark, I'm going to play a little and see how it works out.

The subject is an Atomic espresso machine, I think circa 1950's. This is one that a housemate from my warehouse days owned. I've since rescued one for myself from a second hand shop. I think it's the most beautiful coffee maker I've ever come across - and the coffee is pretty good for a stovetop too. It's sitting on a cupboard in the kitchen of the warehouse I was living in at the time, lit from a window. The image was shot on a Hasselblad, with the standard 80mm lens.

I also purchased an Epson R800 inkjet printer - and I'm absolutely impressed with it. The images are hard to pick from a photo print, only a slight 'thinness' in the midtones - but this might just be my inexperience. They're certainly a hell of a lot better than the first darkroom prints I made, with a darn sight less mess and inconvenience. I'd still prefer to use a darkroom, since nothing beats the sight of a beautiful print fresh from the tray - but my transient lifestyle has ruled that out for years. Thankfully the Epson is a very acceptable alternative, even the matte prints are great - and the results from a scanned 4x5 transparency are stunning.

July 20, 2004

Theory of Constraints (Agile Management For Software Engineering, David J. Anderson)

I've just started reading Agile Management for Software Engineering, by David J. Anderson. In the very beginning he talks about the Theory of Constraints (TOC), which he characterises as finding the constraint in your process (the slowest link) and tuning the entire process to that speed. The effect is to minimise inventory by achieving a continuous flow of production.

I started to wonder how this could be done in my current team. Actually I started to wonder if we were already doing it. It occurred to me that we have a fixed number of people, split into broad categories of analyst, developer and tester. If analysis is our constraint, then by the TOC I should reduce the flow of work to accomodate that. The problem is - what do I do with my developers and testers? If I just leave them idle then I'm realising no benefit, since I have to pay them the same amount anyway (fixed cost). I'm assuming that I don't have the capacity to loan them to other projects (partly 'cos I'd never get them back, and partly 'cos of the return ramp-up cost). Then it dawned on me that if I had developers who could act as analysts, or somehow shift some of the analysis work to the developers - then I'd be able to speed up and keep everyone busy.

Now this isn't really much of an insight - and in fact we already did this when we had a pinch in analysis for a few iterations. We're currently moving some of the work back to the analysts since our new constraint is developement . The insight (and this may be old news to you guys), was that this may be the underlying reason that teams of generalists seem to have better success rates than teams of specialists*. Simply put - you can manage your constraints better if you have people who are able to be moved around. I can't be stuffed doing the maths - but I'm pretty sure you could prove this mathematically. It might very easily end up that a team of average generalist people would massively outperform a team composed largely of skilled specialists - if for example the developers were skilled specialists and the analysts were unskilled specialists or vice verca. (This is amusingly affirming for me, since it's generally recognised by my peers that I'm no specialist - however I do seem to add value ;)

So, it may be that on page n+1, this is what Mr. Anderson is going to tell me - but I was so taken with the idea that I couldn't wait to read on - so someone else can tell me if this is the case.

(It seems to me that there may be some meat in the book with respect to tuning a software development organisation, not just at the project level)

Regards, David.

* I'm pretty sure I read a post about this recently, but I can't find it now - maybe someone could help me out.