Category Archives: Opinion

Thoughts on computers and the IT industry.

Extreme Programming Explained

Introduction

Naturally the key selling point of Extreme Programming — reduced risk and increased fun — appeal to me. I’ve worked on many projects that were either risky, no fun or both and any way to improve that would be a good idea.

However, most of the successful projects were run using fairly heavy-weight methodologies, CMM or ISO accredited, for example. Extreme Programming promises to deliver the benefits while still being simple. I was sceptical. This sounds a little too close to one of Fred Brookes Silver Bullets.

How does it work?

Extreme Programming sounds too simple to ever work. None of its components are new or especially controversial, some are even very common throughout the industry. What’s new is their application together. The key is that the strengths of one part paper over the weaknesses of others.

I won’t detail all the bits — that’s what the book is for — but there are a couple of things I want to talk about.

The one thing that came through in all other reviews of the book was the pair programming aspect. The idea is that whenever writing code, there are always two people sat at the computer. This sounds very wasteful of resources but is based on some very sound theories: reviewing code is good and sharing knowledge around the team reduces the dependency on any one person. XP takes it to the extreme (hence the name) by having, in effect, every line of code being reviewed by two people all the time.

I can certainly see the benefits, but I can imagine a client being very suspicious when you suddenly have two people appearing to do a job you previously only had one doing. He also proposes using a utilisation metric which documents that people are actually not doing genuinely productive work all the time.

Anyone that writes software will immediately recognise that a lot of time is spent helping colleagues, in design or review meetings and any number of other things that are not directly and visibly related to increasing the functionality of a program. Making it more visible sounds like a much harder “sell” than is suggested in the book.

Is it easy to understand?

Brock is clearly very enthusiastic about his methodology and this shows in his prose, which is clear, friendly and concise. It’s sensibly organised and it usually answers questions you’re thinking of in just the right place.

However, it only does all that if you remember what the book is trying to explain. It’s trying to explain Extreme Programming not how to implement it effectively. I had a little difficulty seeing how you could automate tests in some environments. We tried and failed with Oracle Forms (or whatever it’s called this week) for example. I don’t disagree with the principle, but there are some definite technical barriers that are not even acknowledged.

I’m not sure that the distinction between describing what XP is and how to implement it is a good one. It sounds like an excuse to sell two books when only one would suffice. Why would anyone be interested in learning the theory but not the practice of a simple methodology?

Disadvantages

Beck does not claim that Extreme Programming works in all circumstances. There’s an entire (albeit short) chapter on it, which is quite refreshing. Most people would claim that their baby was ideal in all circumstances!

I only thought of a couple of other problems that are not addressed, although neither are necessarily any more of a problem with XP than with other methodologies. (However, they are areas that are claimed to be addressed.)

Documentation is never kept up to date anyway, and in XP there is a much greater chance of at least one person knowing how it works. Couple that with a full set of tests, the ‘business’ person being on the team right from the start and, well, what’s my problem?

The problem is identified in Death March. Who are the stake holders on the project? Is it your team-member (the end user)? Is it their manager, who might want a bunch of reports? Is it the CTO who doesn’t actually care what the system does and just wants a success of some kind in order to get promoted?! The book and the Extreme Programming approach treat the problem of requirements as something that is eventually known and is fix-able given close enough interaction with the users. I wish that were true.

Beck might suggest that this ‘unknown’ is just another form of change than can be managed in the normal manner, but my guess would be that the magnitude of changes required by people that don’t have day-to-today access to the team would be too big and would break the process.)

Or perhaps this is just a size issue. With a system, with a small number of well-defined users there’s no reason it couldn’t work.

Conclusion

I think my initial and immediate dislike of XP stemmed from the fact that most of the projects I’ve ever worked on have fallen into the “won’t work” camp. Now that I understand its background I can appreciate it much more.

And it’s only fair to note that this appreciation comes solely from the book. It’s worth reading even if you don’t plan on implementing Extreme Programming.

The facts

Author: Kent Beck

Cost: $29.95

ISBN: 0-201-61641-6

Dreadful Thoughts

Introduction

I have a terrible confession to make. I am not a spiritual man so, rather than seek penance through the church, I shall document my reasoning here on the web and you can make your own conclusions.

Please go easy on me.

My confession: I can see myself buying a Macintosh later this year.

To some, that may not sound like something to be ashamed of but it’s all a matter of perspective. By trade and education I’m an engineer or scientist; I have short hair, no piercings and virtually no artistic ability (I present the evidence of that here on this web site!). My computer of choice tends to have a barren, baroque user interface. Let’s be honest here, it’s Unix.

The Macintosh and Unix sit virtually on opposite ends of a spectrum. It’s usually called usability, but I think it’s even more precise than that. The Mac makes it easy for people to learn how to use it. Apple make things easy to use and they sacrifice power and flexibility in order to do that.

One of the best examples if this extreme position is the mouse. In Unix you tend to have three buttons. Windows originally had two but now seems to have spawned wheels and more buttons than a Space Shuttle. In each case although it only takes a short time to realise that the left button does most of the useful stuff, Apple decided that one button was less confusing. They’re right, of course. But it does limit your options as far as, say, short-cut menus are concerned.

Unix is the opposite. It has a huge learning curve, but an expert can quickly do just about anything. After spending a lot of time on that curve, I’d actually say that Unix was more usable than a Mac. I’m under no illusions, though, that it’s more difficult to learn.

I guess these extremes, to some extent, explain the success of Windows. Ignoring Apples mistakes and the fragmentation of the Unix market in the early nineties, we can see that Windows is easier to use than Unix but much less so than a Mac. It has the Start menu, Wizards, pop-up help and often hides information rather than bombard the user with difficult, unnecessary detail. On the other hand, it does have rough and ready multi-user facilities, solid TCP/IP networking and a command-line interface (for the brave). It fits the middle ground doing neither task especially well.

The battle ground

That’s how they stand right now, but six months from now things may be very different.

The Unix side probably isn’t going to change much. Linux, especially, will continue with its vast range of incremental upgrades. distributions will eventually come on-line with the new 2.4 kernel, and improvements will continue in both the KDE and GNOME environments.

In the same time-frame, the next desktop version of Windows, XP, will be unleashed on the world. The beta’s are currently doing the rounds and people seem generally impressed. The interface is easier, more consistent and more aesthetically pleasing, and its built on the Windowds 2000 core which has generally been well recieved.

Normally it might have been enough for me to upgrade from my old copy of Windows 95. But for two things: you can’t, you can only upgrade from Windows 98 or above; and MacOS X.

It would be an obvious choice to buy a new PC preloaded with Windows XP since I’ve had a small succession of similar machines over the last ten years, but I find the improvements in MacOS X to be so compelling than I’m considering moving to a completely new architecture. In a sound-bite those reasons are power and user-friendly in one.

MacOS X is based on a BSD Unix kernel (called Darwin and available under an Open Source licence) and has an enhanced Macintosh user interface grafted on top. This is truly the key. You have the complex internals available from a command-line when you need it and a state of the art GUI when you just need a word processor.

In conclusion

There is only one other operating system that supports such a neat combination of Unix and User Friendliness (the BeOS) and that has many problems: I have tried it on three machines and all have had some device that is unsupported, so this can hardly be a unique scenario; and the software support is worse. I may prefer not to use Microsoft Office, but I need to be able to exchange files with people that do.

No other operating system will have quite that level of flexibility. Microsoft won’t be adding more Unix like functionality to Windows and the open source community just can’t compete with the many years of experience that Apple have designing computers for people who don’t write code.

A matter of style

Introduction

The open source community does a lot of things right. The internals of a program is one of them. The people who write code do so because they are proud of what they do and want the respect of other people in the community. The beauty of the code is a very important aspect in this acceptance.

The same isn’t necessarily true in the commercial world. Time-scales are much more important than how the guts of a computer system looks and it’s generally not good to be seen spending a bit of time making your code look pretty.

This column is not going to say that style is more important than substance, but that this interest is something that can bring a large increase in productivity.

Indentation

I know people that hate me for this, but something that really bugs me about some code is the indentation style. I can handle a poorly thought-out, hacked algorithm if there’s a good reason (time usually), but I can never see a good excuse for badly formatted code.

Initially I thought I was being anal, just getting very hung-up on a not-very-important detail, but then I started noticing things. Usually the people that produced the worst formatted code also included the largest number of defects and, although they initially appeared to write code more quickly than me, finished late much more frequently.

Why does that matter?

There are two fundamental reasons why the ‘look’ of the code matters:

  1. Comprehension. How quickly can people understand the code?
  2. Structure. Is it obvious how the program is split into units? Is it obvious what the next statement to be executed is?

I guess they are quite similar, but I feel that it’s important to separate them out. Hopefully you’ll see why in a minute.

Let’s talk about comprehension first. Here’s a snippet of code:

if (x < foo (y, z))
   haha = bar[4] + 5;
 else
   {
     while (z)
       {
         haha += foo (z, z);
         z--;
       }
     return ++x + bar ();
   }

If you've read the GNU coding standards, you might recognise this as an example of good formatting. It isn't.

But there are some redeeming factors. Firstly they've used two spaces for each level of indentation and not a tab. Studies have shown that while people prefer (aesthetically speaking) tabs in programs, those same people actually understand the code more effectively with between two and four spaces. Also, the formatting of the mathematical expressions is clear, with good use of whitespace.

Now the bad. My main problem is with the use of the braces. The lesser crime is immediately after the if condition where they haven't used braces at all. That's bad because a novice programmer might add an extra line below the 'haha' assignment. It probably won't be a valid program any more, but it looks okay at first glance. Since maintenance is the largest part of the software life-cycle, anything that makes updating code more difficult is bad news.

Structure

The indentation of the second half is dreadful, though. Why have two levels of indentation to to indicate one block of code? Again, there are studies that show that formatting like this actually reduces the readability of the code.

My preferred method of formatting the same code would be:

if (x < foo (y, z)) {
   haha = bar[4] + 5;
}
else {
   while (z) {
     haha += foo (z, z);
     z--;
   }
   x++;
   return x + bar ();
}

The main difference is the formatting, but I've also altered the 'return' statement at the end. Side-effects (like using '++x' in an expression) seriously reduce readability as it's much more complex to figure out what it's trying to evaluate. And the solution only takes an extra line...

But why is this a better way to format the code? Simple: it shows the structure of the code more effectively. Since there are only three levels of indentation, your brain doesn't have to work as hard to figure out where, for example, the end of the "else" block is. (It's not so easy to see the advantage with ten lines of code. Try to imagine a page full of code with a large number of indentation levels.)

Some languages appear to be more tricky than the C example here, too. Where does the exception block in Java go? Should the procedure definitions in a package header be indented in PL/SQL?

If you don't really understand block-structure in modern programming languages and are just trying to follow the example of fellow developers, these are probably difficult questions. They're not supposed to be.

A computer will understand any syntactically valid program, but not necessarily in the same way that you or I would. This makes it vitally important that everyone involved has a common understanding of how the program is supposed to work. The first steps to doing this are structuring the code sensibly and making it easy for others to comprehend.

The last important comment is about timing: none of this takes any longer than building your code with poor formatting and structure. Why? Well, if you understand how it's structured it'll be more likely to work the first time. And if it doesn't, you should be able to find the buy more quickly because your code is easier to comprehend.

Summary

To summarise, the neatest, best formatted code takes no longer to write and is much easier to maintain than code that has bad 'style' (although it's much less likely to need fixing).

So the next time that you come across some dreadful, untidy code, try to make the person that wrote it start again. If they don't understand how their own code is structured, neither will anyone else.

You'll note that I keep mentioning studies, but don't reference the source. That's because I've read all about it in Code Complete (follow the link to by it from Amazon.com) and not from the horses mouth. I recommend you also read it for the full story.

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.