Enterprise software doomed?

Regular readers might remember me agonising last year when I subscribed to a pretentious business journal. Well my year’s subscription is about due and the last issue is IT heavy. So, I’ll probably renew for another year. Its not that I read every article in every Sloan Review but I read enough that are of sufficient quality to make it worth the money. Yes it takes time to read an article but the return on investment (financial and temporal) makes reading the journal cost effective compared to books. That is, I get more new ideas and insights from per page than from most books.

There are two articles in the latest issue that are particularly interesting. I’ll leave one for another blog entry and talk here about Cynthia Rettig’s piece ‘The Trouble With Enterprise Software’. This is a well researched and thoughtful piece. It should even win credibility with hardcore coders because it quotes Bjarne Stroustrup and James Noble and Robert Bridle. (Although she forgets the reference for Noble and Bridle;naughty, naughty, wait till I see James. I suspect it is from their notes on post modern programming report.)

Rettig uses ERP software implementations to argue her case but the same argument could be applied to many other IT implementations. ERP is a good example because it shows many of the problems large (internal) IT projects suffer from: multiple stake holders, poorly defined goals, vendor lock in, consultants everywhere, difficulty seeing value, etc. etc.

She argues that basically ERP has failed to fulfil the promise. I has proved expensive, time consuming and locked companies into software, processes and practices. Companies have lost their agility by the very thing that was supposed to enhance it. (She actually uses the word ‘agility’ but doesn’t link it to agile software development or agile anything else so don’t read too much here.)

Further she dismisses SOA as a solution. At the moment a lot of vendors are making a lot of noise, and possibly money, offering SOA as a cure all. I think Rettig is right to be sceptical, those people I know working on SOA problems are finding all the old problems (and a few new ones) just one level higher.

Part of the problem as she points out is that the Lego-brick approach doesn’t work. It is really attractive, like most software engineers I had lego as a kid. (Actually I still do, I just don’t find enough time to play with it, luckily Christmas is coming.) We extend this love of lego building into software. If we could just have simple interfaces... like the 8 studs on a lego brick...

Actually if you look at my lego bricks you will see that only 10% or so are the classic 2x8 blocks. Even before you look at the technical blocs there are 1x1, 1x2, 1x4 ... and windows, and slanted ones, and smooth on one side... although we love this metaphor to build the really cool stuff in lego you need special bricks - and you never have enough of those. The same is true in software, the interfaces get more complicated. The difference is an order of magnitude in complexity.

A further complication Rettig doesn’t mention is our tendency to work at the edge of complexity. As soon as we solve one problem we attempt something more difficult. When we invent technology to solve one problem we find we can use it to do something new. Take XML for example, we could have used it to solve file format problems, instead we are using it to implement function calls (SOAP, XML-RPC) and then SOA on top of that.

We do this because we are chasing innovation and value. If ERP was easy then everyone would have it and it would be no advantage, so you have to do more difficult ERP for it to be worthwhile.

In the end Rettig is pessimistic about our ability to fix the problem, which is nice in some ways. All too often you get into one of these articles and the author says at the end: “the solution is some new technology from my new company.”

Again I tend to agree with her, this stuff is difficult. But I’m not so pessimistic. It is valuable because it is difficult. If it was easy it wouldn’t be worth while. Still, too many companies get into new systems when they should just accept what they have and make it work better.

Rettig does come close to proposing a solution. She correctly notes executives could learn more about IT, and the business schools that teach them could do a better job of educating them about IT. I think this is the answer. Executives need to accept IT is a necessary skill. How many CEO’s would say ‘I don’t understand marketing, I leave that to the Chief Marketing Officer’ or even ‘Accountancy makes my head hurt, I just want the CFO to make it work’ ? But you they can say things like that about IT.

To my mind, more educated executives are a big part of the answer. Which, as it happens, fits with the findings of another Sloan review piece I blogged about last year - Companies who understand IT get the benefits.

This also takes us to the second Sloan piece I want to blog about, but that will have to wait a day or two...

FT piece on business and software agility

The Financial Times carried a piece on Wednesday entitled ‘Agility: Flexibility takes over from planning’. It starts off about agile business but actually spends most of piece talking about agile software development. Both the presence of the piece, and the evidence in it suggests agile is getting more prevalent.

Nice definition of company agility from Professor Donald Sull of London Business School:

“he defines [agility] as a company’s ability consistently to identify and seize opportunities more quickly and effectively than rivals.”

What is interesting about this definition is that it says nothing about what you do, or how you do it. Instead it measures agility by comparison with your competitors.

Slightly disappointing that the examples the article cites are the same examples that come up again and again, Zara, BT and perhaps slightly new, Borland.

If you have the time, this piece from the same issue is also worth a look: ‘Why do so many technology projects end in failure?’ This picks up on the EDS / BSkyB court case I commented on a couple of weeks ago.

Its a shame the editors didn’t link the two pieces. In the long term Agile is about seizing opportunities before your competitors, in the short term it is about delivering IT projects on time, on budget and without court cases.

Reflections on XP Day

I have spent the last two days at the XP Day 2008 conference here in London. A very good conference and highly recommended. Unusually for me I wasn’t speaking at this one which made for a nice change. No worries about presentations, rooms and being in the right place at the right time.

I picked up a whole bunch of ideas, and had another bunch of thoughts. Before I forget them I want to quickly record them - some of these ideas are probably worth an entire blog on their own.

Multi-media keynotes: Both keynote speakers incorporated multi-media elements in their presentation. Jeff Patton included music and Yvonne Rogers video. I think this is a sign of two things: multi-media is becoming the norm; second, people are increasingly bored with the PowerPoint (’death by’) and presenter talking at you (chalk-and-talk) type presentations.

Media companies are more receptive to Agile: A lot of the people attending XP Day had connections with media companies, the BBC and BSkyB were both represented, as were set-top box manufactures, advertising companies and others in the media. Of course there were old industry (pharma, banks, etc.) there too but they have always around.

This is a trend I’ve observed elsewhere. It seems to me that media companies are more receptive to Agile software development than others. There are perhaps two forces at work here. Firstly media companies are fairly new to software as a key part of their business. Yes they always had IT systems but not as part of the product. Agile is the current ‘best practice’ when the BBC, Sky, etc. started to development it was already the norm.

Perhaps more importantly, the second force: media companies expect just in time delivery. You can’t delay the 6 O’clock news because it isn’t ready, you know well in advance you have 30 minutes to fill, and you have to prioritise. The nature of media companies is closer to Agile development so they are more receptive.

Process as a substitute for team work? Of cause Agile software development is all about development process and practice. But scratch deeper and everyone agrees development depends on good people and team working. In fact team working has got more important as software has got bigger and more complex.

It seems to me that a lot of what we call process is actually trying to substitute for team work. We spend time talking about the process rather than the team, we devise process rather than build teams. Somehow we expect the process to substitute for a good team.

Another Agile failure mode: I forget who mentioned this but someone pointed out that Agile teams often fall apart when someone leaves, particularly if that individual is forces to leave by redundancy. This kind of fits with my experience. When an Agile team works well the team bond. The departure of one person is likely to trigger others to leave of their own accord.

Agile Business: This is a topic I’ve been thinking about a lot, so has Chris Matts and others. David Stoughton and Nick Coutts did a great session on the future of business. Not necessarily Agile but a lot of the trends they see in society and the economy suggest the successful business of tomorrow look a lot like Agile organizations.

One point that stuck in my mind above all else was the suggestion that we have moved from a supply economy to a demand economy. Rather than successful companies being those who could produce things the cheapest, and persuade the most people to buy them - a push system - the successful companies of the future will operate a pull system. They will produce what the customer wants, when the customer wants it. Rather than being cost driven they will be value driven.

For my money this was the best session at the conference.

Future of Agile: There are many many software development organizations that are a mess. A little bit of Agile can fix make a great improvement. Agile software development thinking has a long way to run and an awful lot of implementation to deliver. However, Agile has flaws.

One of these flaws is that if you examine in too closely it collapses. The Agile manifesto is actually pretty meaningless, nobody could really disagree with it. If you try and write down a high level value statement of what Agile delivers it sounds pretty much like all the other methodologies and tools that have proved to be snake-oil in the past. Even some of the Agile practices don’t stand up to examination, e.g. pair programming - most developer hate it! Retrospective? - most companies don’t do them.

Agile is still state-of-the-art, the best we have.

It is also a marketing term; a term that collects together a bunch of ideas and allows them to be labelled and grouped together. As a marketing term it is open to abuse.

Increasingly people are increasingly asking: what next?

The people asking this question most often are those with the most experience so some of this questioning is simply boredom, they are looking for the next thing. Some of it is very real and necessary.

(There is some excitement about a new Agile methodology called Kanban, I don’t know much about it and I don’t think this is the next big thing. Something here, but I haven’t had a chance to read it myself.)

So what next?

To me the next big thing will represent a break with Agile. The Agile community came from the Patterns community, Agile is not Patterns. The Patterns community came from the OO community. Patters are not OO. So we shouldn’t expect the next thing to be Agile+.

The next big thing will be People and Team. Software development always comes back to people. Each successive move (OO --> Patterns --> Agile) takes us closer to people. As I said above, sometimes we use process as a substitute, sooner or later we need to address the real issue.

The trick to improving your software development efforts is quite simple: improve your people. Expose them to new ideas, get them learning, help them put those new ideas and learning into action.

More patterns for software companies

I have posted another set of business strategy patterns on my website. These patterns were reviewed at EuroPLoP 2007. It took me a while to incorporate all the comments and then polish them, hence the delay in publishing.

I have now amassed quite a body patterns describing business. At first these were fairly generic, I was writing for any business. Over time I started to think specifically about technical companies and products and now I’ve decided to concentrate on software companies. This is a pragmatic decision, although many of these patterns are more applicable I know about software companies so I can write with knowledge.

These patterns also represent a change in target readership. At EuroPLoP Juregen Salecker pointed out that these patterns would be interesting to people on the receiving end of these strategies and tactics. Yes managers, entrepreneurs and students might find these patterns interesting but really it was those on the sharp end that these patterns are for.

I have another batch of business patterns coming up as a result of VikingPLoP 2007. Hopefully now I have some time I should be able to get these done in a week or two.

My problem, or opportunity, now is that I am amassing a lot of patterns. I increasingly feel the need to pull them all together and look at the whole. Something Cecilia Haskins and Jim Coplien also pointed out at VikingPLoP. Doing this is going to be quite an effort.

And where does that take me?

Well a few people have asked if I would consider turning these patterns into a book. And since two of these people are publishers I need to think about this. However, having just finished one book I’d like a little break... anyone out there interested in a book of business patterns?

Follow up 2: Personal retrospective and strategy

This is the second of two follow ups replying to some comments on the blog. What’s interesting about this one is that its from someone who I don’t know, or rather has chosen to hide their name. Still they have a great memory because they’ve linked something I said a few days ago with something I said last year. Now there’s paying attention! And its good for me because it helps me improve my own understanding.

Anyway this comment asked how I reconciled my comments in the personal retrospective entry where I said I should have done more quicker, with my comment last year (last thing your people need is a strategy) where I suggested managers should spend time observing before acting. Good catch who ever you are.

So, at the risk of sounding like a politician trying to wiggle out a difficult question I’ll try and explain and perhaps I’ll shift my position a little. There is no simple answer so please bear with me...

To some degree it is a question of context. One size does not fit all, and it is important to look at the problems facing an organization before acting. The trouble in the ‘solutions’ oriented world is that you risk applying the wrong solution if you are not careful. Just as it is wrong to apply a predetermined solution before looking at the problem it is wrong to use a predetermined time frame before acting.

Which leads to the question: how do you know what the context is? Well you have to look around, observe what is happening and talk to people. I still believe the people on the ground want to do the best job possible and most likely know what needs doing. So I think its more important to talk to the people doing the tasks than it is to those who nominally control what is going on.

If the people doing the tasks, and those in leadership positions, aren’t seeing the same problems, and aren’t trying to go in the same direction then they positions need to be reconciled. That might mean explaining to the leadership why their model of the world is wrong. Or it might mean explaining to the workers that the company doesn’t want that.

The key point both ways round is not to assume you know all the answers, keep an open mind yourself. Collectively the team will know the answers, and one person may know more than most. I see a manager’s role as unlocking those ideas.

Going back to my personal retrospective post, one thing I didn’t mention was that during my first week at the client I held a reverse retrospective with the development team. This was a little like a project retrospective but since there was no single project to review, and others on the team were also new we had nothing to retrospect about. I call it a “future-spective.”

I gathered the team together for an afternoon and we talked about problems we faced and the problems the management saw. We also talked about improvements we could make and created a long list of things we could do. We then collectively prioritised them and worked out what actions were needed.

One way I would go faster in future is to implement the top priorities on that list faster. I realised when I did my personal retrospective that it took us months to implement some of our ideas, and as a result it took longer to see the benefit and prevented us from moving onto other initiatives.

In future I’ll probably use the future-spective technique but I’ll implement the suggestions sooner. And I’ll go further, I allowed myself to get caught in the ‘no time to improve’ trap in places and after 3 or 4 future-spectives stopped doing them.

As my anonymous commenter pointed out there was quite a gap in the three-month period I talked about last year and the one-week period I talked about recently. To be honest that gap surprises me, I’m not sure why I said 3 months last year, it does seem quite long given what I learned in my personal retrospective. However, I’m also surprised that it only took me a week to diagnose so many issues. So perhaps one week is a minimum and 3 months a maximum, ask me again after I have some more data points.

Again its a matter of context, I’d like to think it is always less than 3 months but I’ll be surprised if its as short as 1 week. In general its is better to delay making decisions until you are sure of the situation but once those decisions are made it is better to act quickly.

One way to ensure that decisions are acted on quickly is to involve more people in making the decision. Although having more people involved may delay the decision when one is made these people share the decision and share the responsibility for acting.

I still stand by my comment that when you are new the last thing your people need is your strategy (actually stole that idea from Lou Gerstner in Who Says Elephant Can’t Dance). However, you do need your own personal strategy. You need to know what you are doing and what you are aiming for.

That personal strategy needs to have a short term element (meet, watch and listen), a medium term element (find problems and opportunities, get peoples ideas, get agreement) and a long term element (do whatever it is you were asked to). And your personal strategy needs to tell you when to wait, watch and learn - something my friend Klaus Marquardt refers to as Proactive waiting.

Follow up 1: Software as an asset

I don’t know how many readers this blog has but I don’t think it s many. In fact I tend to think I know them all. Well, that’s a illusion I can be pretty certain to dispel. I know the ones I know, because they comment on the blog, or they tell me that read it, but by definition I can’t know who I don’t know - if you get my drift. If I now find someone who reads my blog who I didn’t know read it I still don’t know how many reads I have, I just know more of them.

What is gratifying is that although the reader base may be quite small I get quite a few comments. And sometimes I get comments in e-mail not as comments on the blog. So it was that Mick Brooks e-mailed to point out an ambiguity in my blog posting, Software as an Asset, I wrote:

“Your software is worth $10,000,000. Next year, with inflation and depreciation the software may only be worth $9,000,000. So there is an incentive to invest up to $1,000,000 in improving the software, increasing functionality, or code quality, or making it easier to use.”

And Mick asked:

“I don't understand why there is an incentive to invest *up to* $1,000,000 - why
not twice that, or more?”

Well he’s right, I my thinking was sloppy. I skipped several steps in and jumped to a conclusion. The nature of blogging is that it is meant to be fast, what you think of now, not too polished. Anyway, let me think about this a bit slower...

What I was trying to say is: if your software depreciates by $1,000,000 over the course of a year there is a strong incentive to invest in it. At the moment software isn’t carried as an asset on the books, therefore it is worth $0 this year and $0 next year. Therefore, why invest in it?

Now suppose we wish to keep the software worth $10,000,000 each year. We now have to do something to add 10% value to the software just to stand still. Therefore, anything we can do that costs less than $1,000,000 is worth considering. What we really want to do is spend as little as possible to increase the value by as much as possible, i.e. maximise our rate of return.

There are two possible ways value the software. Firstly, remember I imagined a tool that could value our software? Well, what we need to know is what parameters that tool looks at, then by targeting those parameters we can increase the value.

For example, from a product perspective: if adding some new functionality to the system will add value we might do that. Or, from a programmer perspective, if improving the code quality, increasing cohesion and reducing coupling say, will increase the value we could do that. In this way the parameters the tool uses will guide us what changes we make.

The second way we might value the improvements to the software is to look at the effort expended in enhancing it. It is already possible to capitalise the cost of research and development projects, i.e. show expenditure on R&D as an investment on the balance sheet. So, we could argue that spending $100,000 on a programmer to make changes to the software increases the value of the software by $100,000.

We have to be careful with this line of arguing because we could end up counting every bug fix as an asset. WorldCom did something similar with their telephone network and look what happened to them.

Which ever way we value the software the trick is to find the way of increasing the value as much as possible by paying as little as possible - the rate of return. Once you know this you can compare such a project against others in your organization. So, if spending $100,000 to improve the software results in an extra $1,000,000 of asset on the balance sheet it has paid back 10 times.

Conversely, if spending $5,000,000 on a replacement piece of software results in an asset worth $10,000,000 (and the old software is binned) the return is only twice.

But, doing nothing, let the software stand still looks less attractive than it did when the software was not counted as an asset.

Thus, valuing software as an asset gives us a new way of thinking about how we manage the lifetimes of our software.

Back to Mick’s point: my example was a little brief. The real test is whether we can see the value of our software asset increasing faster than other assets. If it is then it is worth investing in. Whether this is a $100,000, $1m a $2m investment.

Personal retrospective

As I said in my previous blog entry I recently finished a major assignment with a start-up client. The company had a lot of problems when I started, and the development group had its share of bad problems. I think I’ve left them in a much better shape than when I arrived.

Last Friday I took some time today to reflect on what it was I did and how I did it. A personal retrospective if you like. This took place between me and my word processor. I just wrote and wrote.... I tried to understand what I did right, that is what I would do again. I tried to understand what I did wrong, things I would avoid in future. And most of all I tried to understand what I would do differently.

To help me I had my personal journal, a diary of events, thoughts and reflections I’d kept during the assignment. The entries were perhaps not as frequent as I would have liked. It started well but after the first few weeks I got very erratic until close to the end. At the time the journal was useful for thinking things through in my own head, understanding what was happening and finding courses of action.

What I found striking was that in the first week I had diagnosed most of the major problems with the development group and company. Some of these I had managed to fix, some remained problems when I left - you can’t fix everything I’m afraid. But it was just striking how much I had worked out so soon.

I normally get sceptical about the expression ‘hit the ground running.’ I’m not sure if anyone really does it. But in this case I’m glad to say I was up and running within a week of getting there.

So what were my big insights from this personal reflection? Two really. Although I consider myself a good communicator (think of this blog, think of the book, etc. etc.) I really could have communicated even more. Particularly upwards.

My second finding: I wish I’d done things faster. There are a few decisions I seemed to hold off doing for weeks but in retrospect worked out for the best.

Any note to myself for the next assignment needs to read: be fearless, go faster.

What is it I do again? (apart from blogging)

I’m at one of those points where I’m considering exactly what it is I do. On the one hand its easy: I manage software development, on the other hand its hard. Its hard because I don’t fall into any of the classic categories we find in software development.

Some of what I do is
• I architect, but I don’t code or write UML; I perform architecture by organising teams and projects. (There is a whole blog entry in that sometime.)
• I project manage, but I’m not really a project manager because I believe that delivering a project involves things beyond typical project management.
• I introduce companies to Agile software development, but I’m not an advocate of any particular methodology.

What I do do, as you can find on my revised website, and the revised Software Strategy website, is:
• Work with the most challenged software development teams to deliver successful projects
• Improve teams so they perform better and deliver more value to their employees
• Align business needs with software development

Why this period of self reflection? Because I have some time on my hands. I have been very involved with a start-up for the last six-seven months and this has now come to an end.

I’m independent, I work through my own company, Software Strategy. I either work as a consultant (I analyse companies and make suggestions) or as an interim manager (I get involved with the running of a department for some months).

I have spent the last seven months working as an Interim Software Development Manager with a company that had a lot of challenges. I help the development team deliver good stuff, I introduced a lot of agile practises. Someone even said I created order out of chaos.

But this has come to an end so I’m looking around for something new. I know the world is full of troubled software groups and I want to help! I really want to help these group improve. Its more than work, it is a passion.

I might not be going to an office each day but I’m still working hard. I’ve done three presentations in the last two weeks, I’m proof reading the final typeset proofs of my book (its almost all over!) and I’ve got some pattern papers to revise or write from scratch.

So if you think I can help your team please let me know. This could be as small as a presentation to your development group (which I did form someone yesterday) or it could be several months turning around a team or introducing Agile.

Book review: Managing the Customer Experience

I decided a couple of months ago that I needed to know more about managing customers. Not necessarily how do you sell, although some of that might be interesting, but more customer account management. Now this is a subject I’ve never really read about before so I was at a bit of a loss to know where to start.

So I hunted around the web a bit, read some Amazon reviews and eventually bought myself a copy of Managing the Customer Experience (Smith & Wheeler, 2002). This wasn’t so much buying a book by its cover as buying a book by review and publisher. Sadly this isn’t the book I wanted.

Rather than talking about how you find your customers, how you satisfy them, how you keep them happy and how you sell more to them it talks about the ‘Branded Customer Experience (R)’. I’m sure the Branded Customer Experience (R) builds to all the things I wanted but its an awfully long way around.

Perhaps the (R) has already given away part of the problem. The guys writing the book have a methodology to sell. Repeatedly uses a registered (R) term in the pages of a book comes across as really pretentious too. In fact most of the advice doesn’t seem that radical or different to what I would expect. I’m haven’t go any real insights from this book.

Plus, the Branded Customer Experience (R) is only concerned with business to business to consumer transactions, I’m more interested in business to business.

So after just two chapters I’m giving up on this book. I’m sure that its a good book if you are looking to create a Branded Customer Experience (R) but I’m not. And I still need to find a good book about customers.

Software as an asset

An interesting piece from Monday’s Financial Times - Study urges IT valuation rethink. What this study says is: IT is an asset, therefore companies should value the asset show it as an asset on the books. This isn’t such a new idea, some people have been arguing this for a while but INSEAD and Micro Focus have written a report and got some publicity for the idea. (See also the Micro Focus press release.)

I have to say I agree with the central argument being made here. IT systems are an asset to a business, they allow the business to operate, they cost money to develop and without them there would be a big hole in the organization. Companies count machines, buildings and even brands as assets but not IT systems. In most companies if the IT system disappeared tomorrow it would need to be replaced and that would cost money.

Actually companies do carry some IT elements as assets - hardware. Mainframes, PCs, printers etc. are bought, counted as assets and devalued over time. So actually, when we talk about putting IT on the balance sheet we are really talking about the software.

Now this has some interesting consequences - not all of which my younger self would be happy to hear. Suppose for the moment software is considered an asset, what happens?

Well firstly you get an increase in your balance sheet. This is good, it shows the company is worth more. It also means that software can be depreciated over time, as with hardware, we can aim to write it off over time. This might make it easier to end of life a system after a period of time. Given that software deteriorates over time this could be a good thing.

However, this also means you can’t dispose of it overnight. How many developers faced with a poor system cry: “We can’t maintain it! We need to re-write it” ? How many managers accept this argument. If software is an asset this decision is changed significantly.

Neither could you throw away failed projects so easily. Many companies bury failed projects. Rather than admit to an embarrassing failure they simply don’t and loose the costs in expenditure. However if you are building an asset and suddenly it disappears then you will have some explaining to do.

For both these reasons (and others) putting software on the balance sheet will make it more difficult to get rid of existing systems. This is the bit my younger self would hate.

When I was still programming I saw lots of really bad software. I always wanted to re-write it and sometimes I did. However rewriting is no panacea. It is often (usually) better for the business to continue with the old system. But in doing so you have to improve it. You have to move it in the right direction or else it will become impossible to work with.

This is what interests me now: how can a business maintain legacy systems? This is the challenge I now embrace as a manager.

Now, if we start counting software as an asset there will be more incentive to maintain the software and keep it alive for longer. This means we will invest in the software to keep the asset. Of course we’re going to need tools to value the software - INSEAD suggest one tool and my guess is Micro Focus can sell you a product to do so.

So what is the net effect?

Well I think this approach would allow better reasoning about the software life-cycle. If a piece of software is only going to be used once then it isn’t going to be an asset and we treat it as such. However if we are going to count it as an asset we can decide whether we are going to devalue it over time, and plan in advance for retirement or replacement. Or if we are going to maintain it and keep (or increase) the value on the books then we need to invest in it. Either way we get to reason about the future of the software more logically.

Now imagine we had a tool that assess software value. Point it at the source code control system, put in some economic numbers and bingo! Your software is worth $10,000,000. Next year, with inflation and depreciation the software may only be worth $9,000,000. So there is an incentive to invest up to $1,000,000 in improving the software, increasing functionality, or code quality, or making it easier to use. That changes the game.

(I’m sure Micro Focus, who specialise in tools for legacy (and particularly COBOL) systems are well aware of this. I for one hope we hear more about this idea.)

We tend to think our software will have a short life. But we already know that some software systems are 20, 30 or 40 years old. (Remember the millennium bug?) These are major engineering achievements.

We take it for granted than major engineering achievements are still there. The Forth Rail bridge was opened in 1890. Nearly 120 years later it still works, it is an asset to the nation. St Pancras station in London was reopened yesterday after refurbishment, originally opened in 1877 it is still an active part of the economy 130 years later and it is an asset to National Rail.

On this basis there is every reason to believe that software being written today will be in in use in 2127. Isn’t it about time we started treating it as such?

Blue White Red - a simple Agile process

My article from last months ACCU Overload is now on my website. This piece describes a simple Agile process which I have used successfully. I don’t claim it introduces anything new or radical. I don’t even claim originality, it derives from SCRUM and XP. All I claim is it worked for me, my teams and has been used in multiple organizations.

What I think is important about Blue White Red is that is shows how you can start to roll-your-own Agile-like process. Start simple with what works for you.

Read the full piece here.