Tag Archives: software

Like magic, the laws of physics do not apply to software

For a few months I’ve been arguing that Agile product/service development only works for classes of systems that are not subject to gravity, like software and business processes. After attending a talk on the functional language Clojure by Paul Williams of @birminghamfp at Agile Staffordshire, I discovered this MITOpenCourseWare 6-001 introductory video.

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/1a-overview-and-introduction-to-lisp/

I particularly recommend about the first 10 minutes. After that you may accidentally learn Lisp and I’ll deny all responsibility for subsequent brain damage if that happens. Hal Abelson argues that ‘computer science’ is not bound by the rules of physics. Like me, he sees the design of business processes and procedures being within its boundaries. Business procedures are just an attempt to implement processes on people rather than in software, sacrificing reliability for flexibility.

I agree that ‘computer science’ isn’t about computers but I think Lean & Agile methods re-take computation for science, rather than magic or engineering. I’m sticking with ‘computational science’ for now.

Many software people are frustrated by their managers’ attempts at business change. Why do organisations allow general managers with no training in the re-factorisation of complex processes to run business change programmes when they wouldn’t trust them to run a small software project? It’s the same thing, but much harder.

Advertisement

The Value of Software

I’ve been reminded of the fastest 1980s transatlantic software delivery method:

  • Put software on a magnetic tape.
  • Put the tape in your hand luggage.
  • Fly to the USA.
  • At customs, when asked if you had anything to declare, say “This tape”. If asked the value of the tape, make a fast decision whether to say $10 and risk 12 hours of interrogation as a possible communist spy, there to steal America’s software secrets or say $150,000 and be sure of an hour of form filling.

It has occurred to me that the correct answer was:
“$10. The licence costs far more but I’m not carrying that. It will be sent on later.”

Software is worth nothing until you use it and only until you stop using it. Free software costs nothing, so developers need to get paid in a different way. Should Free & Open Source Software be paid for only by those who use it to generate a profit and could it generate an international income for the countries that fund it, adjusted for national wealth?

Could we have a licence to receive free software updates, only paid for by businesses, according to their income (before tax fiddles) and routed to the teams that developed the software that is most used? Commercial software could join the scheme too, with higher prices if less rights are handed over. I don’t think it is healthy for FOSS to kill the commercial software market, because it encourages anti-competitive service monopolies like Facebook and Google.

[ This is a first draft of an idea ]

“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.

Management Summary of ‘Social vs Capital’ parts 1 – 3

  1. Avoid hardware vendor lock-in by using Unix-style operating systems that can run on any appropriate hardware.
  2. Avoid software vendor lock-in by using Free & Open Source Software (FOSS) so development can be done by anyone with appropriate skills and shared for the common good.
  3. Avoid service provider lock-in by only using FOSS on Linux to provide services,  operated by multiple service providers in a distributed network with easy data transfer/mirroring between providers.

All 3 suggestions encourage fair competition between competitors in a free market, without the potential to abuse a market-leading position, to the benefit of consumers.