Silver Bullets and the McManager

By Robin Sharp
March 28, 2005

Keeping the project under control...

Schoolbook project management tells us (quite rightly) that you can't make a project faster, cheaper and better all at the same time. You can improve on two of these factors, but at least one has to give. Meanwhile, any "amazing new technology" which can supposedly improve all three factors is commonly dismissed as a "silver bullet", because you can bet it's just too good to be true. But try telling that to your McManager...

Faster, Cheaper, Better: 2 Out of 3 Ain't Bad

I recently had to quickly write a system that risked an awful lot of money every millisecond. The manager had come from the world of system administration. "Mount that drive", "Create that table", "Run that Job" don't have quite the same ring as "Create that automated system". If words were that cheap then "I'd like a bag of diamonds, please." I managed to get good quality software written in a few weeks, but the cost was me, an expensive consultant.

It would be unfair of me to think of the manager of this project as a "McManager". The reason is simple: whilst McManagers do things fast and cheap they at least know they are compromising on the quality. We know the deal with McDonalds: it's fast, it's cheap but if you take your first date there it will probably be your last. Unfortunately the manager I was landed with just pushed for speed, leaving me to stand my ground on quality.

This common sense understanding of compromise brings me back to a diagram that was once on the first page of every project management manual. Unfortunately, like a lot in software engineering, this principle has been left to fade in the wake of fashionable trends. This principle says that you can cannot make a project faster, cheaper and better all at the same time. Something has to give. McManager knows this, IT Manager has forgotten.

The diagram below illustrates these compromises. You can make a project faster, cheaper or better. If you really want to, you can improve on two of the three dimensions, but not all three. You can move around within the triangle, to get benefits, but there is always a cost to your actions.

The Silver Bullets

So we come to the state of the nation, and why I feel the need to write this article. A number of management trends have descended on the I.T. industry in recent years. Each one claims to 'improve' the software that is written. I want to focus on three of these in particular and how they relate to my project diagram.

These three trends are Extreme Programming, Outsourcing and J2EE Frameworks. Each trend focuses on a different benefit. Extreme programming focuses on "faster", outsourcing focuses on "cheaper" and J2EE frameworks focus on "better".

Like all good sales people, the advocates of these management trends generally seem to avoid talking about the downsides of using them. Before I started thinking about these trends I knew in the back of my mind that there was some fundemental incompatiblity between them, but I couldn't quite put my finger on it. Then one evening I was speaking to a friend about McManagement and he mentioned Faster, Cheaper, Better. The next time I thought about these three management trends I realised the missing link.

That's not to say that each management trend doesn't have its benefits. I just don't see how all three benefits can be gained at once.

Extreme Programming

Extreme Programming has raised the profile of some interesting methodological tools. Some good, such as unit testing, some bad, such as pair programming, some ugly, such as minimal upfront design. However, as my mother says "more haste less speed". Extreme programming does have it uses, especially if you're short on budget and need to get a prototype out quickly.

I've been in to rescue an XP project and it's taken a number of very experienced programmers to get a release out the door. The software ends up like a sprawling cityscape, with hidden infrastructure jumping out and surprising you. Good infrastructure is vital for any project. With all the refactoring in the world, if your infrastructure ain't up to it you can dress your rewrite up as refactoring, but it's still a rewrite.

Outsourcing

Outsourcing has proven popular over the past five years. There is clearly a lot of talent abroad and it makes sense for senior managers to try to exploit that talent. However, lack of experience, distance from the business, timezone and cultural differences means that there is a cost to outsourcing. The price you pay is the market price. If you really could get the same software skills for the same price, either those skills will be walking or the price will be going up. The market is a natural law unto itself.

It was Margaret Thatcher who said you can't buck the market. I know large corporations that are now costing outsourcing at four fifths of the price of insourcing, up from two fifths only 6 years ago. The huge infrastructural commitment for only 20% saving in my view will cost a lot of senior IT managers their jobs in the next few years as the business managers start wanting to see the real long term benefits of their decisions.

JavaSoft's J2EE Frameworks

Sun's "official" J2EE frameworks seem to get ever more complex as people try to create a one-size fits all architecture. There is clearly a good argument for large frameworks, as many corporations want to use them. However, frameworks come with the cost of configuration using complex third party software. Since writing EJB's 101 Damnations four years ago, I've seen EJB-1 bloat (EJB-2), now collapse (EJB-3). There is a cost to configuration and distribution and that cost is very high. Developers are starting to turn away from the overbloated 'official' J2EE frameworks to faster lighter Java frameworks.

But... Software Has Improved, Hasn't It?

Maybe management have broken free of these universal constraints. Maybe I'm the equivalant of the Victorian doctors who claimed that a person would suffocate if they travelled at speeds over 30 miles per hour. Maybe I'm not advocating a fundamental law, like the speed of light. Because there is so much money involved and a long history of the principle working, the burden of proof must fall on managers' shoulders.

Well there is one truth. We know that software has been improving over the past 20 years. So if software has been improving, where are the silver bullets?

Let me quickly summarise the three reasons why software has improved over the past 20 years. Whilst this list is not complete I believe these are the three most important reasons.

1. Relational Databases
2. Object Oriented Languages
3. Design Patterns and UML

These three reasons are significant because they are all tried and tested, they have been created out of a real need, and do not look like being improved upon. They are also significant because they are all based on solid engineering principles and not on management principles. Sure relational databases are not all standard, if they were, database vendors would not be able to differentiate themselves. SQL isn't the best language either. Similarly C++ and Java have locked horns as Object Oriented languages. Also people overuse Design Patterns, and UML 2.0 has become bloated. However the success of the technologies that use these are due to the engineering principles that they have followed.

So... why do these engineering principles work better than management principles?

Essentially it's because whilst management moves inside the triangle, engineering can move the triangle itself. All the evidence I see is that the improvements in software are coming from the triangle shrinking, not from management moving projects in three directions at once.

So there really are silver bullets (of sorts), and they're engineering bullets, not management bullets. You can't just move inside the triangle to improve software. Relational Databases, OO, Design Patterns and UML can change the shape of the triangle. Using these engineering principles empowers the programmer to be Faster, Cheaper, Better. However, these engineering principles don't have any public relation history as management tools, as a consequence they either slip under the management radar or management think they can improve on nature (which, sadly, they can't).

Are Extreme Programmers using J2EE in Asia really taking over the industry? You would have thought the "awsome" combination of these management bullets would have been blasting their way onto the software scene. If they are, I'm not registering it. There are good software engineers all over the world, many are moving to better paid jobs, using many different technologies, and many different methods. I would claim that good engineering is what makes these projects better, not any of the magic management bullets I've mentioned.

As for the magic management bullets... I'm sure there will be more because there's a fool born every minute.

Talkback: Have Your Say

Post a new message

Thank you for clarifying my own thoughts
Ian McLoughlin Ian.McLoughlin@pandora.be

Post a new message

<< Back to Soapbox

<< Back to the Front Page