Monday - Continuous Delivery Gone Bad

At the invitation of my erstwhile and erudite colleague and associate Mr. Laver, I went to a presentation by Gojko Adzic at Skills Matter regarding his experiences and recommendations for continuous delivery, one of the corner stones of agile development.

In quite an interesting, if earnest and intense, presentation, Gojko related some interesting anecdotes, and a few novel ideas.

Notable was that to do justice to continuous delivery, it has to be done with multiple versions, allowing mistakes to be made and features to be added without interrupting the work flow of the customers using the applications. There were a few intakes of breath from the audience, and he didn't disguise the difficulties of this strategy, particularly regarding data versions.

Another was the idea of using fast prototyping techniques, often without any coding whatsoever, to be able to sort out business issues, and that feedback and measuring are also important elements, especially if the project is a success.

All in all, it was quite a good presentation, if a little slow in places, and it was good to see how Matt was faring after starting his new job.

Software Metrics with Nigel Runnels-Moss

This evening, I attended a presentation on Software Metrics at Skills Matter. Before I say anything about this, like our M.P.'s, I have to declare a conflict of interest, but first, there's a quote I like from Blackadder III (Amy and Amiability) where Edmund and Baldrick are discussing a suitable bride for Prince George:

Edmund:	Well, there’s Grand Duchess Sophia of Turin. We’ll never get her to marry him.
Baldrick:	Why not?
Edmund:	Because she’s met him.

I met Nigel at the Erlang meeting I attended a few months ago and he didn't create a particularly good impression. Lots of talk, but mostly other people's ideas rather than any insights of his own. Obviously, the following is coloured by my initial impression, so please take that into consideration.

A while ago, I got a book on software metrics called "Codemetrics":

The author, Jonathan Alexander, had read about the use of Sabermetrics (analysing baseball statistics) in creating baseball teams and has applied a similar method to software teams. It's an interesting theory and the book illustrates his point well.

I thought that this might be along the same lines, or maybe about software complexity measures, but it was mostly about the falability of software estimation, something that everyone knows about but can do little to remedy. Unfortunately, Nigel had no new suggestions. He quoted a lot of smart people, including Tom DeMarco whose excellent book "Peopleware" is now available in digital format, Victorian scientist Lord Kelvin and even Fred Brooks got a look-in.

Overall, the presentation was long-winded and meandering: not once was an actual software metric explained in any detail, nor mentioned to my recollection, although I didn't stay to the end. Worse, he quoted some statistics about software failures and reached a conclusion that was highly suspect: software projects above $10 million have a high failure rate, so the more expensive a project, the more likely it is to fail. This illustrates a maxim in statistics called "correlation is not causation", meaning that because two sets of statistics seem to vary in relation to each other doesn't mean they actually are connected. Failed projects cost a lot of money, but a projects' cost has nothing to do with it's likelyhood of failure.

Software Product Development

I've been giving some thought recently to the business of software development. That is, what are the factors to be considered when proposing to develop a software product.

Revenue
Lets take two examples: Microsoft and a company that sells high-end foreign currency trading systems. Both these companies sell software, but their markets are very different.
     Microsoft's customer base is enormous, potentially the total number of PC's in the world, approximately 2 billion by 2012, so even charging a fairly low price of, say, £50 and you only have 25% of that market (new PC's being only a fraction of the whole) you're looking at £25 billion. Actually, MS made $62 billion revenue last year, about £37 billion, but it's still more money than I made.
     For the trading system, the market is very small, about twenty customers at most so, in order to make money, you have to charge enough per unit to make it worthwhile, say, £250000. That gives you a total of about £5 million. If you also charge £100000 for an annual maintenance contract (included the price for the first year) and you get one customer per year, on average, you're looking at £350k the second year, £450k the third and so on. If you do get twenty, you make around £2 million a year. This sounds like a lot, but read on.
     Most companies have a model similar to the latter, but with a lot more customers, and a correspondingly lower price.

Costs
The flip side of revenue is costs. This can be separated into operating costs and overheads.
     Overheads are things like the rent of any accommodation, servicing bank loans, the costs of having an accountant or lawyer. Anything you have to pay regularly irrespective of how big you are.
     Operating costs are usually wages and the taxes that go along with them, plus capital gains and corporation tax. Say a software developer or analyst or tester costs £40k a year. A team of four developers plus an analyst and/or a tester and/or a support person will set you back £280k. A software developer can write about 10 - 20,000 lines of code a year, so it will take four developers upwards of two and a half years to write 200,000 lines, which is the initial size of a system with any degree of useful functionality. Remember that there's no revenue so far (you've no system to sell) so you'll be down £700k by the time it's built.
     There are things you can do to short-cut this:

• Employing a framework of some kind will cut down the amount of code you have to write by anything up to 50%. If that is the case, you can reduce the number of programmers or reduce the time to market. It also increases the reliability, as the framework will have been used by others and a lot of the bugs will have been sorted out. Think Hibernate/NHibernate for Java and .Net. Spring for Java, etc.
• You can use CASE tools which can generate code from models. They've always been of dubious value in a project, especially where reverse engineering is concerned, but if you're starting out, it might save time.
• Open source will reduce the licensing fees, but it's worth taking into account that something which purports to be open source as a development license turns out not to be when you're rolling it out to a customer (see MySQL).
• You can reduce the wage bill by only having minimum wage for the first couple of years and offering stock options: jam tomorrow, so to speak. Minimum wage in the UK is £6.08 an hour which works out at about £13k a year.
• Working from home saves on overheads and is the basis of a lot of start-ups, plus you've always got tele-commuting.

Competitive Advantage
Obviously, you're not the only company selling software products, and you will be competing with other companies even before you start selling. To compete successfully, you have to have a competitive advantage. This is something that your company has that customers want that the others don't, or don't have a lot of. The classic example of this is Google, who have such a large advantage over their rivals that even the mighty Microsoft has problems competing. It's so large, in fact, that it's referred to as a "moat".
     There are many different advantages, but the main ones are price, quality (both of the product and the support) and functionality.

• Price is a reflection of cost (see above). If you're cheaper than your competitors, your customers will come to you, not them, but you have to keep your costs down.
• Quality is how good your software is at doing it's job. Bugs will also cost you money to fix as the customer is not going to pay for you to fix them (but that should be covered in the maintenance agreement). Also the amount of knowledge your support people have counts as quality.
• Functionality is how much work your software does for your customer and how much money it saves him. If your software connects to an external system and, say, creates foreign exchange trades, it means that your customer doesn't have to spend time extracting information to a file from your system and uploading it into the other or, God forbid, creating the trades by hand.

There are, of course, other advantages including customer contact (can you play golf?), business knowledge, etc.

What if it all goes wrong?
You've set up a business and you're eighteen months in. There are no customers to be seen and what one's you have already have a system which is more functional than yours but not as pretty or reliable. Your competitors outclass you at everything apart from the software and are even cheaper than you because they are big enough to undercut you and make a loss just to put you out of business. What have you got to show for your efforts apart from the bills and a load of software nobody wants?

You.

You've been running a business for eighteen months and gained an insight into what it's like to do so. You may have gained desirable skills, such as .Net, Java, PHP or Ruby which you can sell to another company, whether permanently or on contract.
     This all sounds very positive, but commerce is littered with dead firms who tried and failed. If you're young, you still have a career ahead of you and the optimism of better times, but when you are middle aged, everything looks uncertain.