Version 2 "The Rewrite" – don't do it! – never ever rewrite you system

“The second is the most dangerous system a man ever designs” Fred Brooks, 1975 & 1995

Brooks was talking about software designers, architects, but I think the statement holds true not only for all software developers but for the business people who commission replacement systems.

From time to time I come across a team who want to rewrite their system. Usually this is the technology team who are saying “The code is too complex, the thing was written by a jerk, She cannae take it Captain”.

Sometimes is the business side realising that their system looks out of date – Visual Basic 6 controls on Windows Vista, or turn of the century web style.

Either way there is a “Stop the world I want to rewrite” mentality. Sometimes the powers that be buy the argument, sometimes they bless a rewrite or, as one team called it a “Technical Improvement Programme” – TIP for short.

Lets me come to the point: this is always and everywhere a mistake. You should never, ever, rewrite a system just because the technology is old.

This is a mistake because customers don’t want to change. The may think that VB6 controls look odd but they know how to use it. Even if change would benefit them they are scared of it. Plus, they have their own business to run – or life to live – and changing systems is only going to get in the way.

Second, this is an utter waste. Statistics regularly show that as much as 80% of features in a typical software system are not used. So why implement five times more functionality than you need?

One company I worked with commission an cheap Indian company to rewrite an old PowerBuilder application in Java. They were told to make it identical. So they did, they spent a lot of time making Java look like PowerBuilder. They copy every feature, even the ones not used. It was buggy as hell and the users didn’t want it.

Third: the “just a rewrite” mentality leads people to under estimate the complexity involved and to overlook the opportunities for improvement. Why produce a second system which is identical to the first?

Finally, and worst of all: the world doesn’t stop, you can’t afford to stop and rewrite, nor can you afford to waste the opportunity to produce a really good system, one that is better than competitors.

Yes, I agree your current system might be at the end of its life and you might need to throw it away but the solution is not a rewrite. When this happens you have two options.

The first won’t satisfy every problem but is the least risk: refactor your way out of the problem.

Actively encourage programmers to refactor code, of course you need to embraced Test Driven Development at both the development and testing level first of all and start putting tests in. Thats not to say you cover it in tests first and then refactor, rather you start putting the tests in as you go. This is a bit of high-wire act without a safety net at first so I strongly recommend you get some help if you’ve not done it before.

This is real engineering, this is changing the engine oil while the engine is running.

That is the easy answer but it won’t work every time. Sometimes the changes are too much, say from VB6 to C#.

The second answer to develop a new product, a competitor product. One for which your current system/product is the competition. This development effort needs to be market lead and focus on what customers/users want the the current system doesn’t provide.

I’ll say it again: Market led. The marketing department, the product managers and/or business analysts should decide what goes in. Not the developers.

When companies rewrite they jump to the assumption: “The developers know what the current system does so they just need to copy it.” That is the biggest mistake.

Next, get into the market fast, release early release often. Test what you are building in the market, show your company real, usable progress. Remember, your competitor is the current system, if you can’t do better than it you want to know fast.

The objective is to build a system that your current customers want to use, one for which they are prepared to give up the system they have at the moment. Consider this a variation on Same Customer, Different Product pattern (available online or in the Business Patterns book).

Emphasis the things the new system does that the old one doesn’t. Don’t worry about all the features the old one has that you think you need to launch. You might need them in the end but nobody is going to buy your software because it does the same thing. Add them as you need them, you’ll find you need to bring across far fewer than you initially think.

Now I apologise to all the developers out there who are begging their managers to let them rewrite the system. Your code base may be terrible, the technology may be out of date but a development led rewrite is not the answer. Few companies can survive such a thing.

Selling scopeless contracts

The last two blog entries (“Scopeless contracts: the problem” and “Scopeless contracts: the solution”) have been working up to this one. Actually this is the blog entry I set out to write a few weeks ago but felt I had to explain why.

Even if you accept that leaving scope out of a contract for work is the right thing to do you still need to sell it to your customers. This is, perhaps, the real problem. However this is not always the case. Some clients will immediately recognise the problem, or might not wish to sign a big up front deal.

So, faced with a customer who wants to know “How much will it cost to do X ?” what should you say? Or rather, what can you emphasis to persuade them that you have a better idea?

(Note, on anything other than a trivial piece of work X will not be one thing but many, call them X1, X2, X3, … Xn.)

  1. Flexibility: scope less contracts build in flexibility, if the client wants Y instead of, or in addition to X then thats OK. No need to scrap this contract and start again.
  2. Work can go away: Suppose X3 become pointless, then it can just go away without any trouble. As opposed to the UK Government Connecting for Health project [[link]] were actually cancelling the project is more expensive than letting it finish.
  3. Room for innovation: if you sign a big contract and later think of a bright idea then something has to give. Scopeless contracts allow for this because feature negotiation is ongoing.
  4. Bounded by money: Rather than being bounded by scope contracts are bounded by the money available, or sometimes the time available. This forces the creators to work within a very real boundary rather than poorly defined scope and time estimates.
  5. Governance control: bounding the contract in money provides for real governance rather than the governance by proxy that scope, features and line items provide. When the money runs out the work stops. (This of course assumes the team are making regular deliverables, if they aren’t you have even bigger problems.)
  6. Inventive to reduce work: putting 2, 4 and 5 together you get an incentive to reduce the work to be done rather than inflate. In traditional work scope is problem because removing it creates contract problems and loss of face, but more importantly: there is little incentive to remove work until difficulties hit.
  7. Reduce delay & waste, keep options open: All the time spent writing and negotiating scope delays the time when you actually start delivering something. If things change, and the longer you spend writing the scope the more likely things will change, then the more of that work which will be wasted. And the more you think you know what you want the more you constrain the options for producing the optimal solution. Selling without scope reduces this work because scope is derived as you go within the process and only enough is produced as is needed.
You can, and people do, do all these things within traditional scope based contracts but there is additional work to do to change the contract. And, more importantly, it starts the contract with an illusion, a myth: the idea that one day things might be done. Which gives us:

  1. Traditional work relies on a scope myth “scope won’t change”. It does but we pretend it was because something was wrong. The result is we spend time and money managing the myth: managers need to revise contracts, staff change boards, write complex governance reports, etc. etc. In other words: because managing scope is doomed to failure the thing we call “scope” is a chimera which we waste time and money on “managing”.
Despite three blog entries I still don’t feel I’ve said what I wanted to say. This is a topic I need to return to….

Scopeless contract: the solution

In my last blog entry, “Scopeless contracts: the problem” I rehashed all the reasons why including scope in a contract for delivery is a bad idea. So having rubbished the most common way of working I had better explain what I suggest you do….

You have two choices.

Option 1: Set up a ‘Business as Usual’ contact.

The client nominates work to be done and the development team do it. Simple. This is the way most organisations work “business as usual” but once the idea of a project enters the scene people expect the project to have an end date, in order to have an end date they imagine that some amount of work needs to be done.

You can still have an end date but instead of measuring progress against “work to be done” (he scope, the backlog) measure progress against the value added.

After all, software is never finished. If you ever run out of requests for a software product it means nobody is using it. However it might not make sense to do all the work that is requested.

How do you size the team? You don’t, you start small. You start with just the money you can afford to loose. After a while, say three months you review what is bring done and decide whether you wish to go faster (expand) or slower (contract), or perhaps stop altogether.

(Another reason to start small is to reduce the effect of Conway’s Law: if you start big you will get a big programme of work, if you start small you might just come up with a small solution.)

Option 2: Set a Goal, work to the goal

If option 1 isn’t governed enough for you then set an overarching goal. Every three months (or what ever time you decide) ask yourself: are we making progress towards the goal?

You might even want some people on the team measure progress towards the goal (these would normally be Business Analysts). All the work you do should be tested against the question “Does this move us towards our goal?”

If you want more structure use my 10 Step Requirements model.

Yes, it really is that simple.

Drop the backlog. Set a goal. Work business as usual. 1, 2, 3.

The thing is, when you contract with someone to build you software its not like asking them to build you a house. You are buying a service not a thing. If you could buy a thing you probably would have done already. Once you make that mindset shift it all makes sense.

The only complication is, well there are two really: first you have to accept the project model is broken so you need to make more strategic decisions. If you need to keep projects for accounting purposes but projects should have nothing to do with development.

Second you need to do this on a rolling basis, review it every three months.

For most organisations the biggest problem is that they have come to believe the project myth, and they believe it all the way up the hierarchy. Until the people at the top really understand that IT doesn’t fit into the project model its difficult to change.

Scopeless contacts: the problem

I’ve discussed Agile contract models before and I’ve agued against points based contracts (‘Points based contracts? Just say No’) but the more I think about client-supplier software development contracts the more I think including any scope in the contract is asking for trouble.

Before I explain let me say: Yes I know this isn’t going to be possible either with your clients or your own sales folk, I’ll follow up this blog entry with another setting out what you should sell instead.

Now I’m using the word scope, although I hate the word it is the word most people recognise. I mean: “the work which will be done.” Call it a requirements document, a PRD, a product backlog or anything else. Its a shopping list of things you think you want.

Right now, here is why I think fixing scope inside a contract is a bad idea:

Scope is always unknown: you may think you know it but you don’t because things change, learning occurs (on all sides), when someone see something they change their mind about what it is they want, or what they ask for, or what they want next.

I’ve been over this ground again and again, first in Why Do Requirements Change (2004), again in Changing Software Development (2008) and more recently in Dear Customer (2012).

And the bigger your project is the more your requirements will change and grow. Capers Jones gives the industry average as 2% per calendar month for large projects. If you’ve got a project/programme that is up and running you can go and measure it yourself. One team I know saw their product backlog increase by 50% between January and July.

Someone said to me recently: “Surely the team has got better at this now, they’ve learnt.” Well yes, they will have got better, that might take the edge off, might rule out some human factors but the world hasn’t stopped.

The World is Changing: lets suppose for a moment you are running a big project, say its been running 2 years and you think it has another 2 years to run. Cast your mind back 2 years, what was the world like in July 2010 ?

First some context: David Cameron has been British Prime Minister for 2 months, Osama bin Laden was alive and well, few people outside Japan had heard of Fukushima, Deepwater Horizon had just been capped and oil was under $50 a barrel.

  • The first generation iPad had been on sale for 3 months, it was far from obvious that Apps were about to take over the world
  • Nokia were still pushing Symbian phones and were still the biggest mobile phone seller and Android was in version 2.2 (Froyo)
  • JP Morgan was fined £33m for failing to protect client money
  • Greek debt was downgraded to junk in April
  • Barclays were fixing Libor
Go back a little further: Windows 7 was release in October 2009. Further still: the iPhone was released in June 2007 and the AppStore in July 2008. Not that long ago.

Did any of those events effect your business?

Did any of those events, or countless others I haven’t mentioned effect what your business wanted?

Now ask yourself: what could happen in the next two years, to 2014, that would change what your business, your customers want?

President Romney? Grexit? Finexit?

Scope should reduce as well as increase: when you fix scope you also make it difficult for scope to reduce. Requirements should be reducing as much as increasing.

Marty Cagan recently blogged about “The Opportunity Backlog”. Your backlog is not a list of things that will be done, it is a list of things which could be done, and you should do as little of it as possible (its expensive), instead focus on the opportunities which deliver the most.

You human, you make mistakes: well maybe not you personally but the people who work for you.

There are mistakes in what you ask for, mistakes in what you build and mistakes in how people use it. Sometimes fixing a mistake is more important than doing something new.

Second system effect: there is a blog entry waiting to be written about version 2 projects, for now lets stick with what Fred Brooks said in 1975: “The second is the most dangerous system a man ever designs. … The general tendency is to over-design the second system, using all the ideas and frills that were cautiously side-tracked on the first one.”

Whether you are designing from a technical, user or business perspective you suffer from second system effect.

OK, am making my point?

Since requirements can and will change there is not point in writing them into a contract.

This point is doubly dangerous if you attached estimates and timelines to the contract because you will be wrong again. Human’s Can’t Estimate.

This is bad for the supplier who will sooner or later have to explain what is going on to the customer and its bad for customers who don’t get systems that work.

Maximising profit from IT

Following on from last blog entry, IT does matter, more important than ever, I’d like to highlight a study that may have slipped peoples attention. Hardly surprising because the study appeared in an academic journal which is a good place to hide such things – the MIS Quarterly March 2012 (paid for download) if your interested.

Let me cut to the important findings:

  • “IT investments have a greater impact on firm profitability through revenue growth than through cost reduction”
  • “IT investments have a positive and statistically significant correlation with sales and profitability”
  • “an increase in IT expenditure per employee by $1 is associated with a $12.22 increase in sales per employee”
That is, rather than looking to IT to save the company money, i.e. reduce costs, IT spending on generating revenue – innovation, new products, new services, new ways of capturing customers, and so on – is more beneficial to the company.


  • “the effect of IT investments on sales and profitability is higher than that of other discretionary investment such as advertising and R&D expediters.”
So, if you have a few spare dollars you want to invest in the company you are better off spending them on IT than advertising, or research and development. But then, since much of IT – specifically when developing new products – looks a lot like R&D perhaps its not always clear.

And yes, the authors are clear: IT spending has more benefit than advertising. That might come as a surprise.

The research paper speculates on why these findings might be. One reason is that in the Internet age things have changes and IT is now more valuable than it was before. Put this together with my comments in the last blog entry, namely that modern corporate IT may well be able to the customer experience and you can start to see why.

The authors also speculate that the reason why IT does not produce greater savings is a) that many of the savings available have already been taken and b) cost savings are easily copied by competitors while innovations – new products and services – are far more difficult to copy. Which also implies that there is more competitive advantage in using IT for innovation, products, services and improving the customer experience.

(Part of the reason cost saving IT projects are easy to copy might be that they often involve off the shelf software and third party providers – often consultants – who your competitors can also use.)

There is a third finding that is also worth noting:

  • “IT has a greater effect on firm profitability in service industries than in manufacturing industries”
What the paper doesn’t discuss, and I think is missing, is: how do these findings stand up when you consider more-effective and less-ineffective IT. After all, less effective IT can be a good way to through money way. For companies with poor IT deliver performance is IT still a better bet than advertising?

After all, the Alignment Trap suggested that less effective IT performance could lead to a decline in sales. I’d like to see this research go further.

10 years on: IT does matter, more than ever

Just under 10 years ago Nicholas Carr wrote a (in)famous piece in the Harvard Business Review entitled “IT doesn’t matter”. The argument was, post dot-com-boom, that IT was now a commodity, companies didn’t need to spend big bucks on it because they could buy just about anything they wanted off-the-shelf.

At the time my response was, “Is IT worth it?” I, unsurprisingly said “Yes it is” and then looked at Carr’s example of American Hospital Supply. My argument here was that rather than be defeated by commoditisation of IT American Hospital Supply could have chosen to make IT their business. It was a strategy decision.

Anyway, 10 years on. Commoditisation of IT has continued but it is hard to imagine anyone arguing like Carr that IT doesn’t matter any more. Indeed, IT is more important and in more and more cases is becoming the business.

Technology has destroyed the music business as we knew it and is in the process of remaking publishing; television is going to be changed soon.

IT forms the marketing channel now – Facebook, Twitter, LinkedIn.

Logistics is IT based – DHL, drop shipping, Amazon.

iPads, iPhones, Web – are the way you talk to your customers.

And thats the vital bit: information technology, computer technology, software technology is no longer a back room cost cutting tool. It is the customer interface. It is the customer service experience.

Take the travel industry for example. Go back 15 years, 1997. I remember booking my first flight to the US that year. I went into a travel agent, a young lady sat on the other side of the table and poked at a green screen. We talked, she booked me a flight. In 1997 how many of us ever saw the inside of a travel companies IT system?

OK, in 1997 a few were appearing on the web, go back to 1992 and I can safely say: if you didn’t work in the travel industry you didn’t touch travel IT.

IT was a back room activity. Yes the company needed it but the dependency was recent. Customers were unaware of all this.

Today that has changed. This year I’ve booked flights on BA, KLM, S7 and Virgin Atlantic. How I book them – the company web site, Opodo, Expedia, SkyScanner has a lot to do with the customer service experience. I normal start a flight search on SkyScanner, switch to Opodo or Expedia to book and complete things on the airlines own site. If a site is difficult to use I stop and switch elsewhere.

Thats flights. Booking the family holiday is even more IT dependent. Crummy interface, can’t get the answer and I drop the holiday plan and go to another supplier.

I’ve been making this argument for a few years now. So it was good to see McKinsey & Company catch up with me in April when they published “Are you making the most of your company’s ‘software layer’?” Its the same argument:

Software now forms an integral part of the customer service (i.e. buying) experience. Get it right (Amazon) and win big. Get it wrong and you will never be heard of again.

Underlying your delivery might be commodity products but choosing when and where to use off-the-shelf and when to write your own is more important than ever.

Now, imagine for a moment you were a newspaper editor in 2003. You read Carr’s article, you agreed with it, you commoditised your IT. Does that still look like a smart decision?

IT systems might be commodities under the hood but your thinking needs to be ahead of the pack and you need to be able to deliver on what you decide.

Kelly's Law – concluding principles (3 of 3)

Preface: this is the third of three articles on the subject of “Principles – in Software Development” and Agile Software Development specifically. The previous pieces are: Software Principles 1 of 3 and (Agile) Software Principles 2 of 3

Many years ago, so many I’ve actually lost track, but I think I can trace some of these back to ACCU Overload in 2002, I penned my own rules and law of software development. In writing the principles blog entries I though it would be worth revisiting them and seeing if they still held.

(Given that it is so long since I coined these laws it is also a question of whether the next generation of programmers agree with them.)

Kelly’s law of advanced code complexity:

  • Any code that is sufficiently advanced will appear as unmaintainable to a novice (Adapted from Arthur C. Clarke)
This came from looking at C++ meta-programming and some of my own experiences handing over C++ projects – see High Church C++ and The Developers New Work.

I still think this law holds. I still hear from developers who have taken over a code base and find that the original developers used some whacky coding techniques. In some cases the code was simply bad but in a fair few cases it is really advanced stuff. C++ is still the worth offender but Java generics and Aspect Oriented programming also feature.

Kelly’s First Law of project complexity:

  • Project scope will always increase in proportion to resources
I am even more convinced of this law than I was 10 years ago. The more people, time and money put into a work effort the higher the expectations. Plus, add in dis-economies of scale and big efforts are doomed.

You could argue that this law is an application of Parkinson’s Law (“Work expands so as to fill the time available for its completion.”) and I’d be prepared to concede.

Funnily enough, there is another Kelly’s Law, coined by another Kelly, a Mike Kelly (Kelly is a very common name). Mike Kelly’s Law is: “Junk will accumulate in the space available.” Substitute jump with scope, and space for resources and you have the same thing – QED 🙂

Kelly’s Second Law of project complexity:

  • Inside every large project there is a small one struggling to get out
This law is really consequence of Kelly’s First Law. If you have a project with lots of resources the original project will get lost inside of it. All too often the real mission in turning around a failing development effort is liberating the small inner project.

Kelly’s Law of Software Subtlety:

  • Subtlety is bad – if it is different make it obvious – Write it BIG!
This law is really about communication. Its saying “If something is worth saying then say it properly”. I think the law still stands. In many ways the visual tracking, Kanban boards, cards and what not in Agile is an example of this law.

This is also thinking behind The Documentation Myth in 2006. These days I tend to state this as:

  • The bigger a document is the less likely it is to be read
  • The bigger a document is, if it is read, the less that will be remembered
While this has obvious applicability to requirements documents it is generally applicable to just about all the documentation we write.


There you go, over three entries I’ve documented some general principles, some Agile principles and some Laws. Let me know what you think.

Software Principles – Agile or not – 2 of 3

Continuing my theme of Principles, I’d like to outline my own principles of “Agile Software Development”. As I implied last time, these may be simply “Software development principles” but right now I’ll keep the “Agile” word.

1. Highly adaptability over highly adapted

Strive to make you processes, practices, team, code and environment adaptable rather than adapted. The future is uncertain and shows no signs of getting more predictable. Rather than try and predict the future and be adapted to it, strive to be adaptable to what ever may come.

Code design and architecture is a good example of this. Rather than spending a lot of time designing a system for the requirements you think the business wants – they may even aware blind this is what they want and sign in blood – accept that things will change.

Adaptability comes not from exhaustive contingency measures but from simplicity, reflection, learning and change.

Plan, design, for the short term but put in place mechanisms to roll with change. Don’t spend weeks designing, spend hours, be prepared to refactor, put in test frameworks to allow change. Sometimes there are architectural things you can do to allow for change – for example the plug-ins pattern – but these are fewer than you think.

Don’t implement this or any other architecture until you actually see the need for it. Don’t build it because you have a hunch.

2. Start small, get something that works, grow

In keeping with the principle #1 above and dis-economies of scale always start as small as you can, if things work then grow. For example: Start with the minimal viable product, if customers like you product add to it. Start with the smallest team you can, if the team delivers good software people use then grow the team

3. Need to think

Agile is not for those who want to follow a flow chart or for those who want to leave their brains at home and follow procedures. Indeed, if you are such a person then working in IT is probably a bad move in the first place.

Not every Agile method or practices will work were you work. Agile experts and methods disagree. You need to think about this.

You also need to think about what you are actually doing, what you have been asked for, and how you can work most effectively. Unfortunately economies of scale thinking has created a lot of companies whose modus operandi seems to be to stop staff from thinking.

  1. 4. Need to unlearn
Doing Agile practices is the easy bit. The hard bit is unlearning: the things you have to stop doing. If you have burn down charts you don’t need Gantt charts; if you have an automated test suite you don’t need a regression test process; if you have supplies you trust you might not even need a contract; etc. etc.

Things that have made us successful in the past are included here. Teams advance, companies change, to much baggage from the past is carried forward making life in the new world expensive. Remember the words of John Maynard Keynes:

“The difficulty lies, not in the new ideas, but in escaping from the old ones, which ramify, for those brought up as most of us have been, into every corner of our minds.” The General Theory of Employment, Interest and Money (1935)

5. Feedback: getting and using

Agile doesn’t work out of the box, as the two points above say: you have to find what works for you. Some of this might be obvious at first but the more you get into this the more you are dependent – in all sorts of ways – on feedback.

Feedback about the thing you are building. Feedback about the way you are working – as team and as individuals. Feedback about how your customers are responding. etc. etc. etc.

6. People closest to the work make decisions

The people doing the work are usually in the best position to make decisions about the work itself. They have the most knowledge about the work and they have the most immediate need of a decision.

Every time a decision traverse up a decision tree information is lost and delay is introduced.

7. Know your schedule, fit work to the schedule not schedule to work

Easy really. Know when something is needed by and fit the work to that schedule.

In part this principle is a reaction to Kelly’s First Law of Project Complexity – coming in the next blog entry.

8. Some Agile practices will fix you, others will help you see and help you fix yourself

Some Agile Practices – like planning meetings – will administer a fix and you will get a little bit better immediately. Other practices – like retrospectives – will not fix anything but will help you see what is happening and find your own solutions.

Most Agile Practices are somewhere in the middle. Iterations and stand-up meetings are good examples. They may fix some problems immediately – they will improve focus and communication for sure. More importantly they will help people see what is happening and will, in some cases, force you to get better at what you do.

Software Principles – Agile or not – 1 of 3

I should have been at Tom Gilb’s annual gathering this week – GilbFest as some people call it. Instead I’m sitting at 36,000 feet somewhere over Newfoundland heading for Chicago. I don’t often get out of Europe but maybe my fame is spreading.

The theme at GilbFest this year was Principles – defined by my dictionary as “a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.” In fact principles is something that has been on my mind a lot over the last year or so. My “What and Why of Agile” which I gave to BCS London a few months ago featured a few thoughts on principles and I started a blog entry on the subject but never finished it.

Now is the time to finish it. Had I been at GilbFest this is what the audience would have heard about, or rather, this blog entry is the first of three instalments on what I would have said.

Let me say I don’t care whether you call these Agile or not, since we can’t define just what Agile is I’m prepared to accept they may just be principles. That said, I will divide the list into “Software Development Principles” and “Agile Software Development Principles” because I think the first set are universally applicable to software development while the second set require you to at least accept the idea of Agile.

I’ll publish these as separate blog entries, there is a lot here. After that I’ll also return to Kelly’s Law which I penned some years ago – before blogs!

Software Development Principles:

Principle 1: Software Development exhibits Diseconomies of Scale

Many, if not most, of us have been brought up with the idea that if we “do” bigger things get cheaper. Buying 2 litres of milk is cheaper than buying 1 litre. Building 1,000,000 identical cars is cheaper than building 10 different cars 100,000 each.

In software this isn’t true. Bigger teams are more difficult to manage, more expensive and less productive per head than smaller teams. This effect is so pronounced that really large teams might be less productive in total than small teams.

For example: a team of five will, per head, be more productive than a team of 25. Still the team of 25 will achieve more in total than the team of 5. However a team of 50 might be less productive than a team of 25 in total.

And its not just teams. Large software releases are more expensive than lots of small releases. Producing software to satisfy 100 users is more expensive than producing software to satisfy 10, or 1.

The effect appears again and again. Its why Lean folk like to emphasis small batch sizes. Unfortunately post-industrial society has internalised the concept of mass production and economies of scale. You, me, everyone, needs to purge themselves of economies of scale thinking and embrace dis-economies of scale if you are going to be be successful in this world.

By the way, I suspect this applies to other industries, more than we realise, however, I am a software guy, I can talk with authority about software so that I’ll stick to there.

Principle 2: Quality is essential – quality makes all things possible

By quality I’m really thinking bugs, I want to see bug-free software. I definitely do not want to see gold plating, I have no time for reusable code (as I said in an earlier blog).

Philip Crossby said it best: “Quality is Free” – Neils Malotaux puts it more accurately if less dramatically “Quality is cheaper.” The basic message is the same: pay attention to quality, rid yourself of rework and it will work out better. I said more about this in my “How Much Quality can we afford?” presentation.

And when we get to Agile I’m quite clear: if you don’t build in quality I don’t see how you can get iterations to work and I have no hope you will ever truly achieve Agile.

I’ll finish here for now, I’ll continue with the Agile Principles in the next entry.

To finish I should say these principles are a work in progress. That doesn’t mean that I intend to change them when things get tough. Rather I mean a) there may be some more I haven’t get identified, b) there might be some even deeper underlying truth below some of these principles.

Intellectual proprerty

Something else that came up at BCS Edinburgh was a question about protecting intellectual property. To be honest, I can’t actually remember the question but I do remember my answer. So since this is a blog, and I don’t need a question to sound off, let me do so….

Protecting your intellectual property (IP), with a patent, is a good idea if only so someone else doesn’t claim the patent and accuse you of breaking their patent. Offset against this is the time and expense of getting the patent.

I don’t really believe that a software patent can protect your IP from the competition, it can slow down the competition, it can make things expensive for them but then, it also makes things more expensive for you and slows you down.

Certainly if you look at the “patent wars” that Google, Microsoft, Oracle and others are engaged in now its hard to see how any of these companies will really benefit. Sure the lawyers will make some money but will any of it really benefit their customers?

And there in lies the really issue with IP: the customer.

Ultimately customers still have the same needs, the same problems, the same demands. Patents only address part of the solution. If you can find another way of addressing the need the IP is meaningless.

So the solution to all of this is really: Innovation.

Seek to innovate to address the customer needs better.

Base your company on innovation and continual change, rather than patents and attempts to freeze technology at some point.

Stay ahead of those who would copy you by innovating, don’t worry about copy-cats, be onto the next thing.

The fly in the ointment here is patents: if you do do something innovative, and you don’t move to protect yourself – a defensive patent – there is a danger that someone else will. I can’t help but see all of this as a diversion from innovating and addressing customer needs.