Category Archives: Opinion

Thoughts on computers and the IT industry.

Coder to Developer

The concept

I liked the blurb on the back:

“This title addresses all of the skills required to effectively design and develop complex applications, including planning, building and developing the application and coding defensively to prevent bugs.”

It suggests that it can bring you from the stage where you focus entirely on the code to the point where you can take in a whole project, make it all work and delight your customers. Mike Gunderloy has 25 years of commercial experience and so has a lot to say.

As he points out in the early chapters, there is a lot of ground to cover. There is everything from actually writing better code, through to planning, risk management, release management and handling your team. He covers all of these areas, providing handy hints and war stories clearly gleaned from hard-won experience.

For example, I liked the way that he sticks to the things that you need to know, even splitting them up into categoories where it makes sense. Gunderloy seems to be as amazed as I am about how m any projects do not use source control, and he lists Three Levels of Source Code Control Enlightenment, from Opening Your Eyes (just six commands and many benefits!), to SCC Journeyman (which he acknowledges may be all many people need), through to Experts Only (which he spends so little time on that it’s difficult to know what the various options he talks about are for).

Windows Coder to Windows Developer?

What you’ve seen so far is praise for the general concept of the book rather than anything very specific. There’s a reason for that. For a general software engineering book, it’s strange that there is such a strong Windows and .Net slant. There is no need for such details and it will reduce its longevity and usefulness. Steve McConnell’s “Code Complete” is ten years old and is still relevant (even though a new edition has just come out). In six months Coder To Developer could well look dated.

There is also a question-mark over the accuracy of some of the information. For example, he credits the the iterative development process to Microsoft and Rational, forgetting Bohem’s spiral model predated both by well over ten years. He seems to be much more fluent in more recent practises like Agile and XP, which is commendable but seemingly lacking the foundations makes it difficult to put these newer methodologies into perspective.

But if you can ignore these problems, there is lots of good advice. He’s pragmatic ? using the good bits of, say, XP without taking the process as gospel ? and the writing is accessible and friendly. Even disagreeing with some of the early chapters, I still persevered as it wasn’t a dense or difficult read.

The facts

Author: Mike Gunderloy

Cost: $29.99

ISBN: 0-7821-4327-X.

Buy from Amazon.co.uk.

Why don’t developers read?

Introduction

At the moment I’m reading Steve McConnell’s excellent ‘Professional Software Engineering,’ in which he talks extensively about creating a genuine software engineering profession. I believe that this is a great aim and, although I disagree with him on some points, I think the basic premise is both a good idea and inevitable.

However, that is not the point that I want to talk about, although it is related. It’s the fact that, even though I work in a relatively professional organisation, almost no-one here reads computer science books. Sure, there are piles of guides to complex Oracle stuff, C++ this and XML that, but there are no books around on how the whole process should work.

Is there a good reason for that, or are we all really lazy or unprofessional?

Professionalism

I think one of the main reasons is that Software Engineering just isn’t a very professional profession. As I mention above, I work for an organisation with a pretty good reputation for delivering, but most of the people do not come from a computer science or software engineering background.

Bearing in mind the current skills crisis that’s hardly surprising, but is it very wise? Does having more of the wrong people actually help in the long term? (If you work in IT and don’t have a computer science background, I should point out that I’m not advocating a blanket ban. Bear with me for a couple of paragraphs.)

Try and compare what software engineers do with another discipline, say building houses. In IT people are expected to move from testing, to development, to low-level design up to architectural design and requirements analysis. But that’s not how it works elsewhere.

An architect has to study many years at university before being allowed to design a bridge. After a few years hacking together simple programs a software developer may be allowed to design a system. True, a bad computer system is unlikely to be life threatening but it can cost a lot of money. Why take the risk?

What does this have to do with books?

I don’t think that an IT industry split with an elite of architects at the top and developers at the bottom is either workable or desirable, but I do think that we all need to be a little more ‘professional.’ One of the first steps on that road is for people to be familiar with the best practices of the industry and the easiest way to do that is to read.

Knowing where to start can be difficult, especially if you read a different subject at University. As a starting point, my suggested reading list is here.

My list here is not full of dull, academic books, although there are some. Nor is it mainly a list of development books, you need to know some history to put everything into perspective. I just think that all these are valuable and, generally, readable. All IT people at all levels should read most of them.

I’m especially interested in people’s opinions of this list. I’m not as widely read as I’d like, so suggestions are always welcome!

Code Complete,” Steve McConnell

Code complete is one of those books that does the job so well it has no obvious competition. It describes the complete coding process right from low level design through to unit testing and, while most people would have been very prescriptive, McConnell outlines the pros and cons of each approach. If you’re looking for a rational discussion on whether or not you should use a goto in your program, this is the book for you. This book went ten years without an update and the recently released second edition, although extensively rewritten, is, in many ways, not very different (replace the word “function” with “method” and you’re done — almost!). This is not so much a criticism of the new edition as much as praise for the original.

Professional Software Engineering,” Steve McConnell

I make no apologies for choosing another Steve McConnell book. He’s the editor of IEEE Software so it’s not just me that thinks he knows his stuff! This book, as I mention above, talks about creating a real software engineering profession and leaving behind the far too common code-and-fix method that many people are still using. It’s organised as a number of essays, so you can dip into it, but it’s well worth reading cover to cover.

The Mythical Man Month,” Fred Brooks

If you’ve not heard of this book, I’m surprised that you’ve read this far. There should be no need for me to discuss it’s subject matter. If you’ve not read it, you should have.

Accidental Empires,” Robert X. Cringely

I did warn you that not all the books were academic, computer science books. Cringely used to be a writer for Infoworld and so was just the right man to document how the microcomputer industry came about. It’s full of interesting anecdotes, such as millionaire Bill Gates accepting a quarter from a stranger because he couldn’t find a money off coupon, and is well worth investing in.

In the beginning was the command line…” Neal Stephenson

Many people will also consider this to be an odd choice. This is less a book and more a rant about all the different current operating systems, from MacOS to Linux. But the reason you should read it is that its description on why Unix is as it is is the best I’ve seen. Even if you’re quite happy with Windows, you should be aware of the competition.

Cathedral and the Bazaar,” Eric Raymond

Most of the other books here cover the traditional “waterfall” software development model (or at least some derivation of it such as the spiral model). Open-source software has shown that a formal methodology isn’t the only way of doing things. Eric Raymond documents the process and tells paid software developers why it won’t put them out of a job.

Peopleware,” Tom DeMarco and T. Lister

When I first wrote this piece I left this book in the “bubbling under” section, but as time has gone on I have realised that it was more important than I first thought.

Also bubbling under are: Hackers, Debugging the Development Process, OpenSources and Being Digital.

Note: The links above all go to Amazon.com. If you’re in the UK then it’s much cheaper to buy them at Amazon.co.uk. Here are some quick links for all the books mentioned: Code Complete, After the Gold Rush, The Mythical Man Month, Accidental Empires, In the beginning was the command line… and Cathedral and the Bazaar.

The First $20 Million Is Always The Hardest

Introduction

A tip: if you’re going to read this book, don’t flip through to the back and read the ‘Authors note.’ It doesn’t actually give away the story, but there are clues that you won’t want to know. I should know, that’s what I did.

Fortunately, although you can predict the tone of the end of the book, there are more than a few surprises in store.

But I’m getting ahead of myself.

What is the story about?

La Honda is a small, non-profit research centre. They design the biggest, most powerful computers in exchange for sponsorship. The biggest sponsor is a semiconductor company called Omega Logic Corporation, a small competitor to Intel, and they’re relying on the La Honda team to design the next generation chip, the 686.

Andy Caspar, a new recruit, wants to work on this project but, for reasons that only become apparent when you read the book, he’s not allowed to start there and ends up working on a $300 computer. He soon become the subject of ridicule — this is not the kind of project that La Honda are supposed to do. It’s not big, it’s not sexy and it’s not what Omega want.

Andy is eventually hounded out and ends up starting his own company along with the people he managed to lure onto the project at La Honda and the occasional help of his next-door neighbour, Alisa. A battle of wit’s ensues, La Honda and real life against Andy’s tiny start-up,

But what’s it like?

Brosnen obviously knows what he’s talking about. In “$20M” he’s managed to weave a suitably convincing yarn about fictional companies while still leaving the real Silicon Valley (and Redmond based) companies intact. In fact, some of the comments about Microsoft are particularly relevant at the moment.

He also knows the kind of people that work in the computer industry. Even though I work five and a half thousand miles from Silicon Valley, I know people like each of the main characters. They’re likeable and true to life, although some way short of Douglas Coupland’s characters in Microserfs.

And finally, although the life of a start-up seems to involve one good idea, a few people and a fantastic number of long nights in front of a computer — which might have it’s moments but wouldn’t make good reading — Brosnen manages to inject a certain amount of humour and style into the prose. He’s in there with the character rather than criticising them as would have been so easy for a mainstream journalist to do (he writes for, among others, Wired).

Overall

If you’re sick of yet more high-powered books on C++ and CORBA, and need a little light reading, then “$20 Million” might just fit the bill.

You rarely see this kind of thing in real life without actually doing it yourself. This book might be the best, lowest risk way of finding out what its like to be in a high-tech start-up. It’s easy to read, true to life and fun. Not the best book I’ve ever read, but definitely worth a trip to Amazon.

The facts

Author: Po Brosnen

Cost: £6.99

ISBN: 0-09-926828-0

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

Are Your Lights On?

Introduction

I work in the IT services industry. What this means is that I work for various clients using my technical skills to solve their problems.

One thing that no-one mentions while you’re at university, planning to go into this industry, is that most of the problems you come across are not technical in nature. Problems with computers are usually fairly tractable and can be solved, even if not elegantly, by anyone who is interested enough to have a go. It’s the other, people problems that are tricky.

And it is for these problems that I though I could do with a hand: a book about more effectively solving problems. It sounds suspiciously like one of those nasty self-help books, but it’s co-written by Gerald Weinberg (of “Psychology of Computer Programming” fame) so I figured it wouldn’t be all bad.

What’s in it?

The book is split into six sections, each drilling down into particular parts of the problem solving process. In itself this might be quite interesting: solving problems is a process, not necessarily just occasional inspiration. Like any process, once you’re aware of it, you can practise and get better at it.

In one section the authors talk about what the problem really is. At first it sounds silly — you solve problems every day so surely you can identify one! — but the more they explain it and the more you think about it, the more it makes sense. At each point in their explanation, they enhance your understanding with case studies or examples, and often key phrases get their own paragraph highlighted in bold (“Don’t leap to conclusions, but don’t ignore your first impression”).

This level of detail extends throughout the book. They know that some of it sounds silly, but equally realise that you probably do need to know about.

On the downside

For such a small book, there’s a lot of useful information. The hints are relevant and easy to understand. However, I found it all to be an irritating experience. It took me a couple of months to finish and it’s not because I’m a slow reader!

The fact that many of the “case-studies” are incredibly twee makes the whole experience incredibly irritating; I hated the style so much that I nearly didn’t finish it. That would have been a shame.

I’d like to think that the reason I didn’t “get it” was because I’m too old, that format could work quite well in a school book, but I don’t think that school-children would get much from a book about some computer programmers and someone who wanted to fix a lift. It really is a book with content aimed at adults and a style developed for children.

Conclusion

So the conclusion is somewhat mixed: there’s useful stuff in there if you can survive the style. Personally I preferred the more academic, less strictly relevant “Conceptual Block-busting.”

The facts

Author: Donald C. Gause and Gerald M. Weinberg

Cost: $13.95

ISBN: 0-932633-16-1

Buy this book from Amazon.com. Unfortunately it no longer appears to be available from Amazon.co.uk.

GOTO — Software Superheroes

Introduction

This is a book that I bought and read some time ago. I posted a brief review on the discussion forms that used to grace this site with every intention of writing something more complete, but I never got around to doing it. Perhaps that’s because there’s not a lot else to say!

The good: there’s a lot of information in here, everything from the creation of FORTRAN and COBOL to Java and the Internet. It’s all discussed in a friendly, easy manner and rarely gets technical enough to scare off people without a computer science degree. The bad: despite the amount of research the author clearly put in, there’s not a lot new in here. It’s nice having it all in one place but it does, kind of, make the whole book unnecessary. The ugly: they really could have done with some more proof-reading. There are many typos and clumsy sentences that could easily have been improved with some light editing.

Passages such as this show both the good and bad aspects of the book:

“Make the reasonable assumption that … that 1000 lines of code have an average of 17 characters per line, or a total of 17000 characters. So the “lousy” code has 10 mistakes in 17000 keystrokes… that’s lousy for software… but is an extraordinary performance in most any other field of human endeavor.”

I think that this is a brilliant way of expressing the complexity of writing software to someone unfamiliar with the process. However, almost the entire book is written at this level of detail which makes it, very much, a “pop” book, one that anyone can read without getting bogged down in technical details. Personally I like the technical details (yes, sad I know) and miss them here.

Of course my liking of obscure technical details does make the book any less relevant. For someone with a less technical background this book would be a great way to find out more about the process and people beind just about all the software in use today.

The facts

Author: Steve Lohr

Cost: ?15

ISBN: 1-86197-243-1

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

Bored of constant tweaking?

Introduction

This page is just a rant, a way for me to vent my anger. Don’t expect it to be fully rational or for it to make perfect sense. It could, even, be my excuse for buying new hardware; I do like my gadgets.

In fact, this piece is going to be an anti-Linux rant. If you’ve seen the rest of my website this may surprise you. I have, after all, been using Linux since 1994 when I installed Slackware from a knee-high pile of 3.5 inch floppy-discs. I spent a year writing “The Penguin Says“, a collection of Linux application reviews, I have the Oracle 8i Installation HOWTO in the Linux Documentation Project. I’m no fly-by-night, recent Linux convert.

So my rant really starts when I moved house near the end of last year. My flats topography means that the phone point (and, hence, ADSL router) is at the opposite side of the place to my spare room and desktop PC. The choice was to try to stretch an Ethernet cable from one side of the flat to the other or to add a wireless card to my computer. How hard could it be?

Tricky

Very hard, it turns out.

I picked a cheap WiFi card, which may have been a mistake, but it did have Open Source drivers written by the manufacturer. That, I thought, was a good sign.

In practise it kind of work sometimes and it does stutter at times. No fun when you’re trying to listen to music. In some sense, if it didn’t work at all I’d be less annoyed. But it nearly works and you can’t count on it.

Installation

The driver comes in source format along with a utility to configure it. I’m running Fedora Core 1 which has a fairly heavily patched kernel, but luckily it still built with no errors. It picked the “standard” version of gcc rather than 3.2 (which you should use to build the kernel) but that was easily fixed. The configuration tool is also easily built if you have the Qt development libraries installed. It’s at this point that things go wrong.

On next boot, Fedora recognises the new network interface and generates a configuration file for eth1. Unfortunately the driver thinks of the device as ra0 so the OS just gets confused and fails to start the network.

Anyway, to cut a very long and boring story short(er), you need to define the WEP keys, network name and so-forth in the Qt GUI. It appears not to work anywhere else, even though Fedora comes with “standard” tools that should really do the job.

But even then the network doesn’t start when you boot. Instead you start the machine, let the initialisation fail, log into X, unload the device driver using the supplied script, load it in again and then start the Qt configuration tool. The network is now (usually) up and will work for two or three hours before causing a kernel panic.

Conclusion

I’m not really sure what I’m railing against here. It could be my new flat. It could be my old PC. It could be my cheap and cheerful WiFi card. Or its driver. Or the general standard of WiFi support in Linux. And perhaps it’s just because I’ve been spoiled with my iBook and its “just works” wireless networking.

I don’t have any solutions and I don’t really have the money for new kit, much as I’d like one of those G5’s!.

So I’m not sure if you got anything out of reading this, but I think I got something out of writing it! If you’re seeing the same frustrations — and if you have any solutions! — let me know on the discussion forums.