Category: Uncategorized

A copy of ‘Computing’ magazine turned up in the post-in box earlier. It wasn’t addressed to me, but to someone that had left 3 years ago.

I was stunned a) that it still exists – I haven’t seen it lying around on desks like you used to for ages. Years possibly. And b) how thin it is. Back in the day, Computing used to be A3 size and nearly the thickness of the average novel. Now it’s A4 size and about the thickness of the church magazine that drops through my door once a quarter. Not sure what to make of this really.

Oh, and it’s £4.99 a copy nowadays….

Some project managers still seem to have this (albeit unwritten) notion that estimates can be treated as a kind of ‘resource booking’ or ‘Diary Booking’ arrangement. You are allocated to work on one thing and one thing only, you work on it until it’s completed and that’s that.

So if I estimate 2.5 days of analysis, that means I will start on Monday and finish at lunchtime on wednesday, right?


And it’s wrong on many levels. Not least because the nature of analysis is such that you often need to leave and come back to things. Either because you are waiting for the customer to respond or digest what has been presented, or to take actions on their side. In the mean time, one can slot in other work. As long as we don’t have too much work in flight that doesnt get completed thats fine by me. And Kanban and agile is good at managing all this anyway.

I dare say 100% velocity on a piece of work is sometimes achievable, but often not. If anything I would suggest it is often undesirable. To leave something and come back to it can sometimes be a good thing. You see it with fresh eyes. Like composing music (which I do when not doing this) you dont do it all in one go. You have to sometimes step away and come back. It takes time *.

In my case, I avoid estimating on a ‘Diary Booking’ basis if I can. My 2.5 days of analysis might be spread across 2 weeks and rightly so. The The Mythical Man month explored the reasoning behind all of this nearly 40 years ago. Nothing has changed.


* Having said that, developers often don’t like this. They complain about it and call it “context switching”. And sometimes they have point. There is nothing worse than being pulled continually from pillar-to-post and I am not for one moment condoning that which is equally as bad. But working on an IT project is not like fitting a kitchen.

One overlooked technique in analysis is the ability to see issues from various different viewpoints. It is something I personally have always tried to do, and is a critical technique which in general doesn’t seem to be used enough. There are a number of reasons for this – most often, i suppose, it might be because requirements are imposed (at least at a high level) or because schedule pressure dictates that we just need to ‘get on with it’.

Recently I have had cause to revisit the techniques one can use to model viewpoints. They are techniques which change little over the years, and are none the worse for it. Here then, is the first in a series.

#1 – Boston Box

When I was first taught this, it was called the ‘Boston Matrix’. But anyway.

The aim of it is to help you assess your products and services in terms of current and future revenue potential.

The box is divided to four quarters:

Problem Children or Wild Cats (top left)
Stars (top right)
Cash Cows (bottom right)
Dogs (bottom left)

You then plot the position of your products and services in the box accordingly, based on your view of their current merit. I suppose you could separately plot their ‘desired’ or predicted position.

Successful products tend to start as wild cats and the go round the box until they die or get reinvented as something else – a new product or service.

So, the cycle goes ‘Wild Cats’ > ‘Stars’ > ‘Cash Cows’ > ‘Dogs’

If we take an example, and off the top of my head, Internet access via dial-up modems seems a good example – then we get this:

‘Wild Cat’: Internet access via a dial-up modem. In the 1990s this was cutting edge stuff, and the ‘big thing’ in terms of home computing. It’s not profitable at this point but the is an assumption it will become so. I suppose dial-up could have been viewed as a ‘Problem Child’ also, as the technology was so new at the start.

‘Star’: Becomes a profitable enterprise as it strengthens and becomes ‘the norm’, more and more sought after by customers. Dial-up Internet access as ubiquitous at one stage. It Becomes a big earner.

‘Cash Cow’: Became a profitable and consistent revenue earner. Predictable to support. A market leader.

‘Dog’ : Dial-up access got superseded by broadband and people switched away accordingly. Dial-up is still around but a niche optIon and was reinvented as such.

A colleague of mine is involved in a project to modify an existing application that our team are responsible for. For those of you that follow this Blog, the scenario is a familiar one: The application isn’t very well understood, yet it is live and in use. Meanwhile the team that built it have long since moved on and the business area in question has restructured with many people leaving and joining. Oh, and there are the inevitable challenges of budget and timescales.

One of the biggest challenges has been – apparently – getting the developers engaged, given that at the beginning there was a fairly sketchy set of requirements and obviously a sketchy level of understanding about the ‘as is’ situation. So the first step was, quite rightly, to assemble a level of understanding of what is currently there. This of course, requires developer involvement.

“How do you expect us to produce engineering estimates for this?” Came the cry.

And therein lies the problem. Development isn’t always about forward-engineering a solution. It isn’t just about building new features. It’s great if it is, but sometimes development is about untangling what we already have, or reverse-engineering what others have left us. Thats the reality. It might not be glamorous work and might not get you up on stage at an Agile conference, but thats’s life. These activities inform and shape what comes later.

In the meantime we could, I suppose, write a story like “as a user I want the system to work so that I can do stuff” but what’s the point? it doesn’t get us anywhere?

I’ve always taken the view that ‘Analysis in progress’ doesn’t just mean Business Analysis. Analysis can take many forms – It can equally mean technical analysis, or more accurately, a developer prowling round the code to find out what it is doing. The idea that you can start with an “engineering estimate” or even that you can start with “stories”, is nonsensical if this bedrock of knowledge, understanding and investigation isnt there.

My ‘Grand Designs‘ analogy is that if you watch the programme you’ll notice that the problematic building projects tend to be those where they are altering or renovating something that already exists because they are never too sure what they will uncover. Uncovering the unexpected and having the project go awry as a result doesn’t represent some massive conspiracy or wrongdoing, just life. Building something brand new on a plot of land is, on the other hand, oftern far easier and sometimes quicker. Furthermore, it is much simpler to describe how you want your brand-new purpose-built-from-scratch home to look, than to describe how your house conversion/renovation will look, since there might be many constraints and oddities around a conversion that can’t be altered. Not all of these will be known at the start so things may change after you’re underway.

IT is no different. Dealing with something that already exists, is often (if not usually) far more difficult to deal with than a brand-new development. It probably shouldn’t be, but there we are. Also, Agile is at it’s strongest when dealing with the ‘new’.

So, at the risk of repeating myself, the fact is that “Stories” and “Engineering estimates” and all the rest are often the product of the analysis. Not the input to it. Not everything is a new, “green field” development. We are often faced with “brown field” developments – which I suppose are good for the environment if nothing else….

Once upon a time there was a service called Prestel The idea was that by connecting a computer to the telephone line, you could access a remote central computer containing a database of information. A kind of much expanded and turbo-charged Teletext service. Further, and unlike Teletext, you could interact: You could send messages to other users, order goods and services, make reservations, and take part in various multi-user facilities such as chat rooms.

Sounds a bit like something we have today?


Nowadays, Prestel has long since disappeared and is virtually forgotten. IT, never an industry to have much regard for it’s own history and heritage, doesn’t celebrate past advances much. Even important historical figures such as Alan Turing (who is becoming regarded as something of a father of computing) are almost unknown today. It is left to volunteers and enthusiasts to raise the profile of the past. (A tip of the hat to Jason Gorman and others who are doing this).

In one of my less successful predictions (though to be fair, I was still at school when I made it), I thought at the time that Prestel was the future. I thought people would embrace it with open arms. Instead it was pretty much written off as expensive and pointless by most and never achieved more than 90000 subscribers. In a weird twist of fate, the point at which It may have started really breaking through into the mainstream coincided with the internet and World Wide Web taking off. It is perhaps Ironic that one of the reasons for Prestel’s unpopularity was the fact that to connect to it involved the cost of a local telephone call. Yet when the web took off (in the era of dial-up modems – no broadband yet) people seemed to forget that that was exactly what they had to do.

The rest is history. Prestel was dead and buried before it even got properly started.

Should we feel nostalgic or emotional about such things? I do – though I’m not entirely sure why. In a way, you could just dismiss the whole thing as a failure. After all, many printed magazines had more subscribers than Prestel ever did. But it did do one important thing: By planting the seeds of an online world, people could at least see the possibilities for real. It wasn’t just research lab theory – It worked. Technology could deliver instant information and interaction into your home. People hopefully would (and did) get enthused and strive for a bigger, better and more ubiquitous online world. And we all know where that led.

Am I alone in thinking the new iPad 3 is a massive disappointment? It got plenty of media coverage, but I have to say, walking past the Apple Store in Covent Garden at the weekend didn’t show much evidence of frantic queues to buy them.

Question. Do you seriously believe that Boeing and Pizza Hut build their systems in the same way? Hold that thought.

The IT and computing industry is full of people searching for universal truths that can be applied to all situations. Techniques that are totally proven and infallible. Although this statement sounds somewhat confrontational, our industry isn’t alone in this and I suppose it is a reflection of our times: Doing stuff is risky. Dangerous. Not always easy to explain. So it’s natural that people try to look for ways of designing out the risk. That I suppose, is what analysis – in all it’s many guises – is mostly about.

In my 20-odd years in the industry, many different approaches have come and gone. But then again have they gone? Perhaps people have just learned to apply the right set of approaches (or MT&Ts (methodologies, techniques and tools) as people used to call them) to their particular sector: Because whilst it is true that individual projects vary enormously (applying agile to legacy applications is very different to applying it to brand new ‘green field’ developments) there is also an overarching fact that different sectors of industry require a whole different approach. In my view this is also a universal truth.

It seems pretty obvious that if you are working on a system to navigate a spacecraft, manage ambulance emergency calls, or to control train signalling, you need a very different approach to application development to that used if you are working on a data entry application to manage employee training records. Surely there can be no denying that.

In my particular case, I have never worked on spacecraft, ambulance, or train signalling systems and it is quite likely I never will. It doesn’t fit with my interests, skills and expertise. My area is information systems. So in a sense, my opinions – and those of the many writers, commentators and ‘experts’ who haven’t either, can’t really apply their ideas to those cases.

Would you seriously build the examples I quoted using Agile? Or perhaps a better question is “Would you want to rely on the default techniques of Agile? Or would you want to add in something else?”. I don’t know about you but I would. I would want to use something a bit more rigorous than a set of User Stories and scenarios to build something that had human life depending on it. That, before you throw your hands up in horror, doesn’t mean agile doesn’t have a role. I am not suggesting it is dropped. But it absolutely means it has to be augmented by something else, to take into account the specific demands of the sector. You must recognise the differences in how you would approach a project in a different industry.

So. Back to my original question. Do we seriously believe that Boeing and Pizza Hut build their systems in the same way?

Quite clearly: No they shouldn’t.


There are many that will throw their hands up in horror at what I have written here. I even encountered someone fairly recently who said to the effect that “everything should be built to the highest possible engineering standard”.

This is rubbish of the highest Order.

Well, it’s a view anyway. But it is like walking into a Ford dealership and asking why the cars aren’t Porches: As human beings we can clearly build something better than a Ford, so why aren’t we? We should all demand and expect Porches, right? Why would we settle for less? This argument is quite obviously nonsense. We live in an imperfect world with budgets, compromises and constraints and much as we may object to it, a Ford is often acceptable. The alternative, sadly, is quite likely to be an imperfect solution or no solution at all.

An interesting article appeared the other day in the newspaper I was reading, about on-demand catchup TV services. It made an interesting change from articles about reality TV shows, Big Brother and X-Factor. For those of you that follow this Blog, we’ve been here before: I’ve written about it a couple of times now, firstly in an article called ‘the demand for on-demand’ and latterly in one about radio. In both cases, my views are basically that on-demand services are great, but show no signs of replacing traditional broadcasting.

Quite refreshing then, than some industry figures seem to agree with me then – outside of the broadcasters themselves.

‘On-demand is a hugely important contributor to the consumer television experience but it won’t naturally replace or inevitably replace scheduled television,’ insists Simon Woodward, chief executive of ANT, which provides software for television sets and set-top boxes for clients such as Samsung.

What many of the technology ‘gurus’ and ‘experts’ often fail to grasp is simply that different technologies can co-exist. Just as microwave ovens didn’t replace traditional gas or electric ovens (though I dare say there were people around when microwaves first emerged that would have predicted exactly that), it is perfectly reasonable to have both. Radio listening continues to be strong despite iTunes, Spotify, LastFM, podcasts and everything else. People enjoy both. Cinema is still prominent, despite blu-ray and 3D. Theatre wasn’t killed off by television. I could go on.

Of course none of the above have remained unaltred and untouched over the years. They are not museum pieces from some bygone golden age. Television channels, though popular and with audiences going up if anything, don’t get anywhere near the audiences they once did. The infamous Eastenders ‘Den and Angie divorce’ storyline from 1986 got an audience of 30 million. Lets repeat that. Thirty million. Today the same programme gets audiences of around 7 million.

The days of 30 million viewers for TV shows is clearly over. And it is unlikely that we will see these sort of audiences again in our lifetime. But the point to remind the technology ‘gurus’ and ‘experts’ about is that those days were over long before the Internet. Long before on-demand, iPlayer, broadband, and the rest. The unstated subtext that the catch-up services – or Internet generally – is bringing about these sorts of radical changes and a decline in broadcasting, simply isn’t true.

How is it that in the internet age, audiences for traditional broadcasting services seem to be going up?

I haven’t the faintest idea. And neither do the ‘experts’.

I hear a lot of talk about ‘on time and on budget’ and it is often held up as the pinnacle of human achievement. And perhaps sometimes it is. But as with so much in life, there is often more to it.

But when people talk about the virtues of these two things, I get a bit niggled by it.  After all, what about the work itself?  And more importantly the implications of the work itself?  It that less important?  This may come as a shock to some, but there are cases where ‘on time and on budget’ may matter less compared to doing the right thing.  The right thing is what people remember, and is why we are here as IT professionals, surely? This doesn’t of course mean money is no object and it is open season to do whatever we want. It’s simply that different projects and situations sometimes need different treatments.

Remember this?:

Project Management Triangle

As we all know, ‘time’ and ‘budget’ (or cost) are only two points of the project management triangle: ‘scope’ (or maybe to put it differently  ’doing the right thing’) being the third.  Furthermore, it is an equilateral triangle: ‘time’, ‘budget’ and ‘scope’ matter equally.  

These three things are constantly competing with eachother, but at the same time you can’t have all three. That is the dilemma. The outcome may well be different on each piece of work. And this isn’t an indication of insitutional failure or acts of wrongdoing. It’s just life. There is no need to philosophise further.

Unfortunately, take away ‘time’ and ‘budget’ and the what you are left with is probably the most difficult part to explain and understand.   Is that why it conveniently gets left out?

I am sick to death of the stories circulating about London’s high-tech district being in the ‘East End’. It bloody well isn’t. Most of it seems to centre around Old Street and City road. Well when I worked round there, we never regarded it as ‘East’. If anything it is ‘North of the City’ or even ‘The City’ (depending on the message the sales people wanted to give out). City Road where I was, is EC1. Not the east end. The Barbican – a few minutes away – can in no way be described as ‘the east end’. The Bank of England is in EC2 (geographically further east than Old Street) but no one would describe the Bank of England as being in ‘the east end’.

Oh, and Hoxton, a few seconds away once you cross over City Road into Hackney, is N1! N1 is not ‘the East End’ either.

I take it no mapping companies are based round there..