They call it the pallet method. Not waiting until all pallets are known, but start loading the truck from the moment the first pallet is presented.

This method has as said some setbacks: it is only valid if the architecture and infrastructure are in place and known.
You always run the risk that the truck is too small or that the first pallet has to be unloaded at the first address. It also usually implies that the space in the truck in not efficiently used.

So you analogy with the butcher would be valid if you had to choose between beef for a gas stove or for a electric stove, where the number of flavours you are going to use determines the price.

Lets call it an incremental fixed price project (or something in that genre) then, I still don’t like the analogy to the butcher . I think that also, for the first few “sprints” — scrum lingo — this kind of accounting can be difficult, because a minimal foundation of a project has to be put in place, setting up the environments… So there would be a startup cost involved as well — “features” the client hasn’t asked for.

If I’m not mistaken this kind of accounting is already used for delivered fixed price projects, when change requests are asked for.

So you can think of it like this: your first release is very basic, almost no real features. Then the client asks for changes (features) which are accounted for one by one.

In reality, I think this kind of development will overall be more expensive, because every time a new feature is requested, there will potentially be a lot of impact, compared when features are roughly known beforehand.

@Michael Pichler
I roughly agree with you.

The main issue is still: if you go a butcher and order a piece of certain meat, you and the butcher know the “characteristics” of that piece of meat, and in addition, those are well defined (not just by you and the butcher).

But there is no such definition for software or even components of software (unless you go to get a packaged product with its advantages and disadvantages). If the customer agrees to use that model and you get payed by function points (or any other unit) the customer still doesn’t know up-front how much or what he will get and how much it will cost in the end, unless you find a way to define it up-front.

One aspect that’s definitely good for the customer with this model is: he/she will pay for functions and not for effort spent or planned. So the risk is up to you, the provider of the software (component).

Just my two cents

Cheers,
Michael

I disagree (and subsequently agree with Shoogend), you don’t have to approach this like a fixed price project. What if you were working on an agile project and you got paid by the point? I have seen that work. The butcher doesn’t have to design or grow a cow like we don’t have to deal with registers and bits anymore (I understand it is taking the analogy a bit far). The butcher does have to design (cut and cleave) the meat and package it according to his craft.

I work in a model like this, because it creates a natural tension to do good work. I get paid for what I do, and get paid less for mistakes. This seems self evident to me that I should be paid based on the merit of my work.

Good blog.

Of course any software engineering analogy is flawed in some way but I like it for the point Sander is trying to make.

The analogy of the butcher is obviously flawed. He doesn’t have to design and grow a cow, before he can deliver the meat.

You can buy software by the kilo, just grab a retail package of the shelve in a store and go pay for it.

kind regards,

Jeroen