Tag Archives: cost

The Unvexing

This post comes to you courtesy of Graham Lee at: http://www.sicpers.info/2016/11/the-vexing-problems-in-programming/ who reminded me about Value. We agilists (people who believe in agile software development) talk about value a lot but haven’t  agreed on a consistent definition of the word. As an illustration of two of the options:

“The value of this car is £9,500.” Is that to a seller or a buyer? Unless there is a difference, no trade will take place. Or is it a market rate? The long acquisition dance between Yahoo! and Google makes an interesting case study. This is: a value. A ‘fact’, right or wrong. It is the kind of thing developers in imperative programming languages put into variables and mutate but pure functional programmers squirrel away for ever, to embarrass themselves at their past Wrongness.

In contrast, “This car cost £9,500 pounds. I think that was quite good value but the model that costs £1,000 more is even better value.”, is a relative benefit:cost calculation, yet the manufacturer may market a ‘value’ model, which is just cheap. This is: a value judgement. An explicit or implicit comparison relative to something else, followed by a decision. It is a computation.

When Graham says, the most vexing problem of software product  developers is their inability to “compare the expected value of their work to the expected cost of the work.”, I think he means  ‘business benefit of their work’, and cost normally equates closely to development time. All the customer really wants to know is: “Is this the best investment I could make now?”

Graham goes on to say that we are very bad at estimating how long something will take. This is true but we are much better at estimating small jobs accurately than large ones.  Uncertainty increases exponentially with length of sequence of actions, to slightly corrupt Shannon’s Information Theory. This is why the Fibonacci sequence is often used as a sizing tool.

Agility accepts this reality. It addresses the list of things the customer currently wants, in highest benefit:cost ratio order (guessed by a business domain expert, based on guesses by an agile develooment team.) It doesn’t yet know whether the ‘whole job’ is worth doing. It decides only whether to risk the next small, cheap step and keeps doing that, as long as the ‘value’ is Good Enough. While value is high and risk is low enough, keep going.

A journey of any length starts with the first step, so why worry about whether or not it is going to be 1000 Miles? The hard part is to make it a journey, rather than simply wandering about, lost.

Then there are: our values. Our personal decisions about what matters most to us. Do we go home to read our children a bedtime story or work late and win that promotion so they have greater financial security in the future? What do we really care about and what are we willing to pay for it? This too is relative. Politics is the art of persuading you to modify your personal values. Currently, cheating is allowed.

“Agile Project” is an Oxymoron

From http://en.wikipedia.org/wiki/Project:

“In contemporary business and science a project is defined as a collaborative enterprise, involving research or design, that is carefully planned to achieve a particular aim.

Projects can be further defined as temporary rather than permanent social systems or work systems that are constituted by teams within or across organizations to accomplish particular tasks under time constraints”

Projects are risky, slippery things, particularly when made out of software, which is notoriously difficult to get a grip on. Large companies take big risks with projects so have to protect themselves with governance systems and project portfolio management and project managers to take the blame. Project managers become highly skilled at batting blame away.

The effect of all this insurance is that projects become even more expensive. The smallest software project may have a start-up cost of £50K, used to build the corporate control structures necessary to get permission to begin. This makes it a very bad idea to run any small software projects, however good their apparent benefit:cost ratio. You want nice chunky projects to spread that £50K of overheads across.You’ll think of something.

Assume you didn’t – say you ran a project that only cost another £50K to complete. You would have spent £50K to insure yourself against £50K of risk, while exposing yourself to the new risk that your project might be rejected, which would have cost you £50K to do nothing. That would be CRAZY!

What is project management? You write a specification that precisely defines your aim. This is generally described as ‘the scope’. Then ALL YOU HAVE TO DO is achieve ‘the aim’ (which is hopefully in some way related to ‘the scope’ – no-one is quite sure) while balancing the famous ‘Time, Quality, Cost triangle’ on your head. It is unlikely that you will get any actual definition of the Quality that is required, so if the triangle falls off, that is clearly the side you should aim for it to land on. Luckily, quality is unlikely to be tested until the end of the project when either the time or the money will have already run out, so it will be too late to do anything about it and you win. We now refer to this method as ‘Traditional’, much like Morris dancing or cock-fighting.

What the cool-kids are doing these days, in their fancy Internet start-ups, is called ‘Agile’. They don’t have a whole load of cash to spend on insuring themselves against risk so they cunningly avoid it; or at least minimise it so that it doesn’t need to be managed. They don’t do a year of work to decide and plan what they are going to do over the next 5 years. They say “What do we need right now?” and “What can we achieve in a month?” and then they do it. They might make a big list of what they’d like and guess it could take 2 years with the resources they have but after a month they have some software that they can hopefully use. If they are happy with it then they decide what to do next month.

So there isn’t really anything you could call a “particular aim” or “a scope”, or indeed any long-term “time-constraint”. As long as each month of work promises to deliver value, you can carry on. Or you can stop because you can think of better things to do with your money now.

In total it is not, in fact, a project.

Clearly there is a down-side to all of this. There must be, mustn’t there? You can’t build a house or a bridge or a car without planning! But software isn’t a house, or a bridge or a car. Modern software is built out of objects, like Lego bricks in zero-gravity. You can change things later, at reasonable cost.