Category Archives: Opinion

Thoughts on computers and the IT industry.

Death March

Introduction

Perhaps more than any other engineering discipline (see Steve McConnell’s After The Gold Rush), software engineers work on projects that have no real chance of success. There are as many reasons why as there are projects, but if you want to be in with a chance of surviving such a ‘death march’ this could be the book for you.

Content

Edward Yourdon is a well known and well respected computer scientist, so what useful information can he give you in these circumstances? Surely you’re lumbered with the simple choice between putting up with it or resigning?

Well, no. The book explains that there are any number of things to do, and not just for the project stake-holders. There are things that just about anyone on the project — and indeed just outside the project — can do. And quitting is almost always one of the options he gives. I find this interesting because most books tend to argue that you can fix anything. Sometimes you just don’t have the authority to do anything that would make a significant enough change.

Of course, it’s a two-hundred page book, so it doesn’t just launch into this resign-or-fix discussion. First he talks about what a Death March project actually is, and then moves on to finding who the key players in the project are. These people are not always those that you think should be in charge! For example, the CEO’s golfing partner is often in a position of power and influence, although you won’t find them in the organisation chart. (I’ve seen these kind of dynamics in play, but I hadn’t really though about it in these terms.)

He then moves on to negotiating the best deal for you and your team in this bad situation. You may not be able to get your boss to accept a rational argument at the beginning (or even towards the end) of the project, but you should at least try. And these are the arguments to use!

Motivation, both from the various clients and in your own team, play an important role in the success or otherwise of the project, and are discussed in some detail. One vaguely controversial statement is that we all need to be involved in politics to some extent. I agree with the ‘why’ — even your boss may secretly want your project to fail — but I don’t know how. Many, maybe most, of the developers I know have absolutely no interest in politics and try to pretend that it doesn’t affect them!

The next two chapters talk about methodologies and tools, and their applicability to death march projects. The last chapter discusses integrating the death march into your companies culture (most of your projects are going to be like that anyway, so you may as well get used to it!).

Controvacy!

It’s not all good news, though. Some of the chapter on staff motivation is hard going (or at least would be for the people on your project). One of Yourdon’s correspondents suggests that, on a death march project, people should be putting in at least 60 hours a week! I know that some people do that, and that it is encouraged at some companies, but I really don’t think that people should be encouraged to do that on a regular basis. It’s only fair to say that Yourdon goes on to say that people working over 60 hours a week need to be watched closely, but by then the damage may already have been done.

Generally, however, the advice given is very pragmatic. I’d like to think that most of it was obvious, but it isn’t. This is the kind of information you probably realise only after years in the business.

Overall

I’m sure you can guess by now: I’m impressed. Most Computer Science books are not this sensible and are frequently based in research in university labs rather than commerce. In fact, I’m pretty certain that I’ve never seen a book that recommends that you resign in certain circumstances!

It’s not just the detail that makes this an important book. Yourdon backs up his assertions with examples and email’s from colleagues that discuss some of the options available.

If you work in IT, sooner or later you will end up working on a Death-March project. This book is just what you need to be able to tell what chance of success it has and whether you and your organisation will survive it. Highly recommended.

Details

ISBN: 0-13-014659-5

Price: $16.99

Buy this book from Amazon.com or Amazon.co.uk.

Whats with Windows 2000?

It is now two days after Microsoft’s official release of ‘the next generation’ of their premier operating system, Windows 2000 (n?e, NT5). We’re now at a safe distance to be able to assess the impact it has had on people and the press.

The first interesting thing to note is that on Slashdot, the Internet’s favorite site for hacker-oriented hi-tech news, did not make any announcement. One argument is that Slashdot is Linux, or at least Unix, biased making Windows news irrelevant. I don’t buy that. What Microsoft is doing is important if Linux is to achieve world domination.

The real answer came as a comment to another thread (about a new development kernel release), not by the sites editors. 17th February is not really a very significant date even to Microsoft. The software has been available to big customers — the main target market — for months and even smaller customers should not have had too much difficulty finding a copy. The only significance is that you can buy a shrink-wrapped copy. Big deal.

But should you buy a copy?

This brings me to my second point: despite a sprinkling of pro-Linux-is-Microsoft-doomed? articles, almost all the press I’ve read pretty much follows the line of Microsoft’s PR company. Whatever happened to reasoned, critical journalism?

Since there’s so much of this, I’m loath to identify individual magazines or articles, it just wouldn’t feel representative. The kind of thing I’m talking about are blanket statements such as “Windows 2000 is faster, more scalable and more reliable than NT.”

Where do they get this from? There is certainly no ‘real world’ evidence of this. If you discount this months release, people have been trialing the OS on small, test systems for a few weeks. Without a realistic load who can say, honestly, that it’s more reliable? And does ‘more reliable’ just mean ‘better than NT4’ or does it mean ‘as good as ‘Unix’? (Personally I believe neither interpretation. I very much doubt that a first release can be as reliable as NT4 with all the service packs, and that’s before we get to the months of uptime you can expect from a well configured Unix box.)

If reliability is difficult to understand, more scalable is laughable. At work we’re using a four processor Xeon 550Mhz machine with tonnes of disk-space. Right now there are very few Intel boxes that are bigger than that. Okay Win2K may support that hardware better than NT4 but it’s still the biggest you can get. An equivalent Sun machine probably falls into the ‘midrange’ category. What happened to the Alpha support? What happened to the PowerPC port? Both these architectures are far more scalable. And Linux, popularly believed to be less scalable than NT, supports them all.

So far, this piece is definitely painted as an anti-Microsoft tirade. That’s not going to change substantially, but Microsoft does deserve some credit for getting something the size and complexity of Win2K out the door at all. Check the metrics and success rate of projects that are thirty-five millions lines long. And there are some nice features. The GUI admin tools are not matched on any Unix implementation I’ve used and some things, such as the file protection and the separation of web applications from the web server, are long overdue.

However, the late delivery, high price and Microsoft-only nature of many new features don’t help in Microsoft’s defense against the monopoly allegations.