erwan's code blog

Today, I received it.
It was waiting for me when I came home, humbly wrapped in a flat usps envelope. It had come to me at last, all the way from a second hand bookstore in a remote corner of the USA. Now it was lying in front of me, on my kitchen table, looking at Stockholm's skyline through the windows. At last we meet, me and the famous 'Peopleware'. This book is almost impossible to find nowadays. Yet it is revered by many (well, mostly software developers) as a must read to be placed in the pantheon of software management wisdom together with the 'mythical man month' and the 'pragmatic programmer'. I have heard so much about this book that I feel like I have already read it. But it feels good to reach to the source.

I know of a software developer who upon meeting a new boss starts by giving him a copy of this book. If I was to choose and hire my own boss, I would undoubtedly check whether his views on software development match with those of Peopleware.

Indeed, it is far too common to see software managers who haven't even acknowledged the most simple of all facts: that software development is more about sociology than technique. I have too often seen, at my working place and other places, measures taken to supposedly improve efficiency that in fact only killed a developer's motivation and creativity. But motivation and creativity are hard too measure, much harder than project completion grade and spent man hours, so managers who mistreat the human factor tend to go on with it unnoticed of their superiors.

Anyway, for the next few days, me and 'Peopleware, productive projects and teams' by DeMarco and Lister are having a date...

This evening I attended to a seminary given by Andy Hunt, the co-author of 'The pragmatic programmer', one of my favorite computing books.

He gave a one hour talk starting with the title 'how hard can it be'. Funnily enough, this happens to be the motto of one of my colleagues who likes to fire it each time some truly impossible assignment falls on us...

The talk was entertaining. A lesson in how to make professional presentations: concise slides, tons of jokes and a truly enjoyable speaker. Having read (and reread) (and read again) the said book, my expectations were high. So I got a bit disappointed at the slow tempo and low rate of fresh ideas. Still, it is honey to my heart to hear rehearsed what I so sincerely believe in...

The talk boiled down to: software development is truly really hard because it has become the center of the universe. Indeed, everything nowadays depends on chips, and more precisely on the programs running on those chips, and thereby on programmers.

Programmers have to translate into code precisely everything man has thought of, which implies that programmers have to understand in details a scale of things that stretches from the extremely technically arcane (bits,
hardware design, os guts and floating point arithmetics) to the extremely humanly arcane (laws, stock exchanges, poker rules, the inside of customers heads). Of course, it is impossible. That's why things get so hard.

Nonetheless, programmers have to cope with amazing complexity. And some of it is self-induced: bad habits, wrong abstractions, ill-adapted tools... To fight complexity, one has to strain to keep things simple, which starts by choosing the right tools.

This is a nice conclusion. Nobody would argue against it.

Yet choosing the right tools raises a number of issues, not all of them technical in their nature. Assuming you actually know which tools are the right ones for the specific problem you are facing, how will you convince others in your team to convert to them?

As Andy Hunt stated (free adaptation): "I can refactor myself a bit, but I really don't know how to refactor others". And truly, refactoring others is hard. Otherwise, communism would have succeeded, which it didn't. Quod erat demonstrandum.

So what would the pragmatic programmer do?
I actually asked Andy that question and was eager to get his opinion. His answer was: convince by example. Try the new tools, new languages, new abstractions on your own, as a side project, and show the result to your colleagues. Don't push them. Let them come to you.

This answer was really sweet to my hears, because as a matter of fact it is exactly what I have been doing at work for the past years. And it has worked well.

It is quite amazing how little software development really is about developing software.

I have too many private books at work. I wouldn't even notice if I was missing one. Time to make an inventory. From left to right, and up to down:

* Joel on software (Joel Spolsky)
* Code complete 2edition (McConnell)
* Effective perl programming (Hall & Schwartz)
* Types and programming languages (Pierce)
* Programming pearls, 2nd edition (Bentley)
* The mythical man-month (Brooks)
* Design patterns (Gamma, Helm, Johnson & Vlissides)
* Perl6 and parrot essentials (Randal, Sugalski & Tötsch)
* UNIX systems programming for srv4 (Curry)
* Mysql & msql (Yarger, Reese & King)
* Agile & Iterative Development, a manager's guide (Larman)
* Object oriented software engineering (Bruegge & Dutoit)
* Modern operating systems (Tanenbaum)
* La programmation en pratique (Kernighan & Pike)
* Java in a nutshell (Flanagan)
* SPARC architecture, assembly language programming and C, 2nd edition (Paul)
* Understanding the linux kernel (Bovet & Cesati)
* Introduction to algorithms (Cormen, Leiserson & Rivest)
* TCP/IP illustrated vol.1 (Stevens)
* The C++ programming language (Stroustrup)
* Le language C (Kernighan & Ritchie)
* Unix network programming (Stevens)
* 4.4 BSD operating systems (McKusick)
* Applying UML and patterns (Larman)
* Assembleur facile
* Javascript precis et concit (Flanagan)
* Tcl/Tk pocket reference (Raines)
* GNU emacs pocket reference (Cameron)
* Perl/Tk pocket reference (Lidie)
* HTTP pocket reference (Wong)
* Perl debugger pocket reference (Foley)
* CVS precis et concis (Purdy)
* Perl5 precis et concis (Vromans)
* Emacs precis et concis (Cameron)
* sed & awk pocket reference (Robbins)
* La bible PC programmation systeme, 6th edition
* La bible internet
* La bible linux
* Les reseaux (Pujolle)
* Programmation en Perl (Christiansen & Schwartz)
* Exploring expect (Libes)
* Hacking exposed, 3rd edition (McClure, Scambray & Kurtz)
* Intrusion detection (Escamilla)
* Intrusion detection (Bace)
* Java security, 2nd edition (Oaks)
* Java network security, 2nd edition (Pistoja & cie)
* Algorithmes genetiques (Goldberg)
* Cryptographie appliquee (Schneier)
* Malware, fighting malicious code (Skoudis)
* Security in computing (Pfleeger)
* Cracking DES (EFF)
* Javsacript, the definitive guide (Flanagan)
* Win32 system programming, 2nd edition (Hart)
* Exploiting software (Hoglund & McGraw)
* Hacking, the art of exploitation (Erickson)
* Malicious cryptography (Young & Yung)
* Naissance d'un virus (Ludwig)

Like probably most developers of my age, I haven't learned LISP at school nor used it for anything more than hacking .emacs file.

But I have heard of LISP. Sometimes in horrified tones ("parenthesis hell!", "gives me headache!") but most often with awe and from people whose opinion deserve respect.

After reading Paul Graham's book "Hackers and painters" I felt an increased curiosity about LISP and purchased Peter Seibel's "Practical Common Lisp". I recently had a 2 week vacation and started reading it.

My first reaction was a kind of surprise: I did knew a bit of LISP! The pocket computer I learnt to program with some 20 years ago, a Hewlet Packard 48 (HP48), was a kind of LISP machine. Not so surprising in fact considering how widespread LISP was in the 80s.

The familiarity stopped there. My HP48 is a piece of computing history, while Common LISP is a fully matured language with features that leave me dreamy. Macros to name only one.

I can relate to my own experience with Perl.

Perl is a fairly advanced language. It has closures, higher order functions, evals, threads, introspection and more. Lately I have been trying to extend Perl's syntax to support a form of programming by contract. I started implementing that by using dynamic code generation: letting programs self-modify during runtime. It can be done with Perl, but it requires a rather heavy blend of evals, string manipulation or even opcode-tree hacking (for the hardcore suicide candidates) and ends up being clumsy and limited. Recently I have been trying source filters to help on the way.

In LISP, I could have done that quite simply with macros.

Source filters are the closest equivalent to LISP macros that perl offers. Yet, there is a significant difference between them: LISP macros manipulate LISP code that is already expressed in a form that makes it easy to manipulate by other LISP code (those so-called S-expressions). The perl code of a perl source filter manipulates other perl code in the form of a string of characters. A perl source filter does not understand perl code, which makes the act of altering the source quite hard since all parsing knowledge has to be built into the source filter. And it is wellknown how hard perl is to parse... To gain the full strength of Common LISP macros, perl would need a mechanism for interpreted perl code to self modify itself. There is since recently a CPAN module for parsing perl from within perl: PPI. I wonder how that could be combined together with source filters in order to get closer to LISP macros...

This book is amazingly well paced by the way, and should stand as an example for anyone writing programming language books. It is available online: www.gigamonkeys.com/book/

After 4 months of waiting and a number of delivery incidents, I finally received my copy of 'Types and programming languages' (Benjamin Pierce's famous TAPL).

That completes the series of my recent book-shaped mind-extending acquisitions: 'Haskell, the craft of functional programming' and 'Practical common LISP'.

I sat at home this morning and delayed going to work half an hour to just get to read the first chapter of TAPL. Damn! It's like taking a long warm shower within your head! It cleanses your mind, puts names and shapes onto old foggy ideas and insights, puts a structure on everything! Suddenly, I start thinking more clearly. And that was only the first chapter...

If you have time to spend and are looking for neural stimulation, here are short articles about software, gathered by Joel Spolsky (the man behind Joel on Software) as part of his compilation 'The Best Software Writing vol.I'.

Visitor meet my Bookshelf. Bookshelf, meet Visitor!



This is a (quite spontaneous) picture of my bookshelf at work, where I have moved most of my private programming books since I usually don't have time to browse them at home.

I believe you can judge a developer by the books he/she stands for.

Computer books are many. Every new little idea leads to myriads of books poping up like snails after the rain, most of them with far too many pages and far too little content. Yet a few authors have managed to see beyond details and fashions. Here are a few books that have made me into a better developer:

"Code Complete" by McConnell
"The practice of programming" by Kernighan and Pike
"Programming Pearls" by Bentley
"The mythical man-month" by Brooks
"Introduction to algorithms" by Cormen, Leiserson and Rivest
"Modern operating systems" by A. Tanenbaum
"Higher-order Perl, transforming programs with programs" by Dominus
"The Pragmatic Programmer: from journeyman to master" by Hunt and Thomas

There are of course many more books worth reading (and not least those I just don't know of ;). There are excellent books focusing on one or another programming language, on protocols or operating systems. But those listed above are about knowledge that lays beyond the specificities of platforms and languages. They provide a bit of the distance that one normally acquires only through many years of intensiv and varied coding. They are a source of enlightenment...

You have seen my books. Now you know who I am ;)