Category Archives: Opinion

Thoughts on computers and the IT industry.

Engineer or Hacker?

Eric Raymond would have us believe that everyone that develops software for fun is a hacker. I know that historically this has always been the case, but that doesn’t necessarily make it the right thing. All good, and bad, things come to an end.

I doubt that it will happen any time soon, but I think that ‘hacker’ is a term that should whither and die.

The first problem, and this is the obvious one, is the public perception of it. Yes we all know that hackers write code while crackers break into computer systems, but how many people ‘outside’ know that? How many professional software developers, i.e., those who do it just for a living rather than for fun, know that?

If even professionals don’t know the difference, how can the rest of the population have a chance?

Of course there’s always the fanatical wing, those that claim that we should hit the problem face-on. We should call ourselves hackers because we know that we’re right and that everyone else is wrong.

It’s actually a very politically correct way of doing things, but I remain unconvinced that it works. Richard Stallman continues to insist on the term ‘free software,’ even though most people find it more confusing than ‘Open Source.’ None of this is about changing ideals or opinions, it’s just about the correct marketing of the term.

The second problem I identified is much more subtle. What does the term ‘hacker’ mean? My dictionary defines it as follows:

hackvt cut, chop (at) violently;

It goes on, but that’s the important part. My objection comes from the lack of precision that the term implies. You get a program and violently cut and chop it around until, by chance, you get something out at the end that seems to work okay.

I hope you don’t develop software like that, I certainly don’t. Any half-decent developer follows a process, no matter how ill-documented. When you debug software you don’t just dive in adding ‘print’ statements all over the place, guessing where it goes wrong. Instead you make a hypothesis and test, modifying your original until you get a good idea what’s wrong, then you start with the ‘print’ commands or your debugger.

Does that sound uncontrolled and violent?

All that planning and precision, all the experience that it takes to be able to make a reasonable and accurate hypothesis sounds more like engineering of some kind.

And that it why I call myself a Software Engineer rather than a hacker, even when I write code in my spare time.

Minolta Dual Scan II

Introduction

Oddly, the main reason I’m writing this review is that I feel that the Minolta Dual Scan II has been harshly treated in the media. Most magazines seem to skip over this, the entry level, model and move on to the Scan Elite. On photo.net all are singing the praises of expensive Nikons and Canons, and complain about the lack of ICE on this model.

In a sense they are right, but everything is a compromise. Here’s why the Dual Scan II is a compromise that works for me.

What is the Dual Scan II?

Flat-bed scanners have plummeted in price over the last few years. Just seven years ago the only way most people could own a scanner was by getting one of those hand-held ones that you manually dragged across your document. They were quite neat, but getting a good scan was tricky. You needed a steady hand and lots of patience.

Fast forward to the present day and you can get good and cheap flat-beds for reasonable prices. You don’t need a steady hand, just the patience — much less than used to be the case too — and a computer capable of accepting large image files. Most of the pictures you can see on the site have come from a very cheap flat-bed, so why did I go and buy a new one?

I have only very occasionally scanned anything other than my own photos. At first glance, a flat-bed seems ideal for the task: simply place the print on the glass and scan away. What’s wrong with that?

Image quality. Each stage the image goes through loses information. By taking the picture rather than looking at it directly with your eyes, you lose information. Scanning it in loses more and printing it onto photographic paper does too. So scanning from a print loses more information than scanning directly from the slide or negative.

Many flat-beds have a transparency adaptor, but I’m not impressed. Most scanners operate at between 600 and 1200dpi, which is great (too much really) for prints, but slides and negatives are much smaller so you’ll need to enlarge them to print. And negatives come out a funny colour. Much better, I thought, to get a scanner dedicated to scanning the originals.

Hence the Scan Dual II. It scans at 2820dpi, which is nearly three times the resolution that I could expect on a reasonably prices flat-bed. It’s much better than a digital camera, too. That resolution is roughly equivalent to a ten mega-pixel digital. Don’t bother looking in the shops for one of those just yet.

It’s designed especially for the task I’m interested in, meaning that you can automate some of the process. I can do up to six negatives or four slides in one go. It’s smaller than any flat-bed and conveniently connects to my iBook’s USB port (many other scanners in this price range are SCSI, which is difficult with a laptop). And it comes with software for the Mac, albeit only MacOS 9, which is another major consideration!

I see what they mean

I spent so much time in image editing software trying to correct the colours of my scans that buying a new scanner was worth the effort. To my eyes, the colours produced by the Minolta are fantastic. It’s able to find details in the negatives and slides that you can’t see in the prints.

It’s kind of obvious in retrospect, but now I find that I’m still spending time in Photoshop (much less through). The problem now is dust. When the source is so small, even small motes of dust look huge. I guess this is why people are happy to pay another few hundred pounds getting a scanner with ICE software. I’ve still not found a 100% reliable way of cleaning my negatives yet, so please let me know if you know of one!

But, as I said, it’s all a compromise. I could have brought a pretty good flat-bed scanner for half the price of the Dual Scan, so I stretched myself getting it. Spending more for ICE just wasn’t an option.

The software that comes with the scanner seems to be quite powerful, but does stop some way short of real image editing software. They supply Adobe Photoshop LE for that purpose, which is getting on a bit. It’s a cut-down version of Photoshop 5. Since we’re now on version 7 it’s rather ancient, and, like the scanning software, is not OS X native.

Conclusion

Slide scanners are very expensive compared with flat-bed scanners. Not only are they tasked with scanning much smaller sources, but far less people buy them. This means that in the broader scanner market, the Dual Scan II is horrendously expensive.

But as far as slide scanners are concerned it’s great. There are cheaper scanners, but they work at much lower resolutions and are only able to work on a single exposure at a time. The more expensive models tend to have image enhancement software which, while useful, is not worth the extra for someone with my (lack of) artistic abilities.

The bottom line is that if you’re on a limited budget, or would rather spend more money on camera equipment rather than computer peripherals, then I consider the Dual Scan II to be a good buy. However, the ICE software on the next model up are quite possibly worth the money.

Note: Some time ago I emailed Minolta technical support to ask them about a MacOS X version of their software. I was surprised when they said that they were not going to produce one. I was, therefore, even more surprised when I recently found said scanner software in a native MacOS X flavour. Ed Hamrick’s Vuescan shareware application is still a viable option, especially if you want to scan negatives (on which it does a far better job out of the box) but I think I’ll be sticking with the “unavailable” Minolta software.

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.

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.