PSD Top!

Hi there! I'm Duncan White, an experienced professional Unix programmer.

Welcome to my Practical Software Development (PSD) pages.

Back to my Personal Pages.

Welcome to Duncan White's Practical Software Development (PSD) Pages.

I started these webpages in May 2007, and have recently started extending them again (Feb 2011). What are they all about?

I'm a professional programmer, and have been programming for well over 20 years, mainly in C and Perl, although I know many other languages. In that time, despite my best intentions:-), I just can't help learning a thing or two about the practical matters of designing, programming, testing, debugging, running projects etc. And in recent months, I've been discovering - and rediscovering - some absolutely fantastic books about Practical Software Development. By coincidence, the three main software development books I've (re)read lately all have titles of the form "P..P":

  • The Pragmatic Programmer (Hunt & Thomas) - see my Review here. Referred to as H&T throughout these pages.
  • Programming Pearls (Bentley) (and the sequel More Programming Pearls) - see my Review here - referred to as Pearls throughout these pages.
  • The Practice of Programming (Kernighan & Pike). Referred to as K&P throughout these pages.
I'll add a review of K&P soon.

Inspired by those three excellent books, and by some vaguely formed thoughts of mine over the last few years, I'm going to write a series of articles - discussions, tips and tricks, some book reviews, more general thoughts - about interesting program development topics. If you're a professional programmer, you'll probably have already read some of the books I discuss, and probably had some of these thoughts as well. But I hope maybe I can tell most people about some new books and techniques. Please drop me a line if you do find them useful..

Several themes will run through many of these articles. Many of these are derived both from experience and from the above three books. Some of the most important themes I will return to again and again are:

  • Use K&P's core principles everywhere: simplicity, clarity and generality.
  • Show pride in your work - do a thorough job whenever you program.
  • Automate wherever possible. There are many occasions to use different automation techniques to make your programming life easier. Look out for them actively.
  • Develop your own toolbox as your experience develops. Write flexible reusable ADTs, modules and tools, and reuse them aggressively on new projects at the least provocation.

One note: although most of these discussions are intended to be general, most of my examples will be in C and (especially) Perl, simply because these are the languages I use most. As will become clear quickly, I not a fully paid-up member of the Object Oriented (OO) squad. I use OO techniques whenever they seem appropriate, but I'm equally at home with procedural/modular techniques. I find there is a regrettable tendency amongst OO pundits to pretend that nothing good existed before OO techniques, and to reinvent earlier excellent practical techniques, stick pretty OO labels (terminology) on them and call them new and shiny. For example, separately defined components with clean interfaces and information hiding (i.e. "modular programming") have been a standard programming technique for an awfully long time before they were ever dressed up as "classes".

Many terms have been used over the years for these components - "components", "modules", "packages", "classes", "units" to name but a few. Whatever terminology is used, most of the core modularity concepts are the same. I'll use the term module to describe such a component, whether ostensibly object-oriented or not. "Abstract Data Types" are a special case of module, where the module is defining a new type and all the operators that act on it. Sounds very much like objects - but perhaps without inheritance.

dcw@doc.ic.ac.uk
Updated: June 2011