Tag Archives: review

Dreadful Conclusions

Introduction

I still can’t quite believe that I did it. I actually bought and Apple Macintosh, just like I said back in February. After years of using Windows and Unix is seems a little odd, but I think I like it.

There’s a lot to like about it, though. Here are some of my thoughts as a Windows and Unix user.

Hardware

It was the combination of the new, white iBook and Mac OS X that swayed me in the end. There’s no way that I’d buy one of the original iMacs and my budget didn’t stretch to a PowerBook no matter how much I wanted it to.

One thing that I really like is the hardware. Unlike most PC’s, it feels as though it’s been designed rather than just thrown together. Even compared to my old Dell laptop, this one feels well put together.

Having said that, it’s not perfect. I’m sure that it looks neat on all the design sketches, but I can’t imagine that having all the ports down one side of the machine is the most optimal way of doing things. For once, it probably works best for left handed people! The ports are all down the left side so the mouse cable goes in the correct side. Unfortunately I’m right handed…

Also, it’s deliberate that there are no flaps over the ports. The idea being that there’s nothing to snap or fall off over time. On the other hand, I’m sure that means that they’ll fill up with fluff and other random detritus.

Unlike most PC’s, Apple have completely parted with the past. There are no serial, parallel or PS/2 ports (not as though you’d ever expect PS/2 ports on a Mac). This has bothered me less than I imagined it would. The main down-side is printing to my parallel-ported Deskjet, but I managed it using my Linux box as an intermediary (and Postscript interpreter). Not the ease of use that Apple imagined!

The last thing I’m going to mention about the hardware is something that is an after-thought with most machines: the power-supply. Basically it’s tiny, only just bigger than ink cartidges for the aforementioned Deskjet. After using laptops with power-supplies near as big as the computer this came as a surprise.

Software

I didn’t buy the iBook for it’s hardware, though (although that was important!). I got it for Mac OS X. As I mentioned before, Mac OS X is a rather neat combination of a BSD Unix kernel and a Mac-like user interface. On paper it looked fantastic. It has all the things that the original Macintosh operating system lacked, such as a real networking stack, multi-threading, pre-emptive multi-tasking and the ability to use more than one mouse button. (Okay, I’m joking about the last one.)

The incredible thing, after all the disappointments I’ve had comparing marketing literature with the real thing, is that it does deliver.

In the previous section I mentioned that I now print using my Linux box as a server. It’s not pandering to any Macintosh oddities. Mac OS X is sending print jobs directly to the Linux print spooler, just as another Linux or Solaris machine would. Very neat.

Another thing you can’t really see from screen shots in magazines is how good it all looks. Semi-translucent windows, drop-shadows instead of borders, the way loading programs bounce up and down in the dock, the way that progress bars and the default button in dialogs pulsate… They’re all completely unnecessary, but totally cool. It makes working with the machine that much more fun.

Fun. Now there’s a word you don’t hear in connection with Windows very often. Linus Torvalds wrote Linux “Just For Fun” (his book), whereas Windows was written purely for money. I guess they’ve both succeeded in their own goals. I hope Apple can profit from their combination of both.

Annoyances

There are only a few things that I really dislike, and some of them are rather petty.

Firstly, Apple are still not too confident with it. When you get a new machine it defaults to starting Mac OS 9. If you’re used to dual-booting your PC between Windows and Linux you’d probably expect a menu when the machine starts up asking which operating system to start (that’s what I was thinking). But no. You have to find the Startup Disk control panel, change some settings and restart the machine. Not difficult when you know but not in keeping with the well known Macintosh user-friendliness. (Apple have just announced that they’re making OS X the default OS. This has not been well received by many, who are waiting until Quark and Photoshop are native OS X applications before switching.)

The other things are really niggles. For example, in the Finder although you can search for NFS and (presumably) Apple shares, you can’t browse Windows shares. (Of course my Linux box only had SMB shares at the time…) In fact, I’ve not been able to connect to any SMB shares on my server yet. However this “problem” has not been widely reported so I think that we can assume that it’s my local configuration.

And this is the churlish complaint: they’re updating it too often! Within days of getting hold of the machine there have been many megabytes of fixes. Which is kind of good, but the upgrade to 10.1.2 is 30Mb, rather a lot over a dial-up line especially when dropping the line means you have to restart the download from scratch.

Conclusions

Stepping away from what used to be called IBM Compatibles seemed such a big step. At this stage I half expected to be annoyed with myself, and cursing spending all that money on something I didn’t fully understand how to use.

The key has to be its value. I want to be able to access the Internet, edit MS Word compatible documents and write software. The iBook can do all that using free or preinstalled software, comes in a very neat package with some unique features

It is still kind of odd having to think about how to do some things that are “obvious” to me in Windows and Linux, but I’m still of the opinion that it’s worth the hassle.

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.