How hard can it be?
November 15, 2007
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.
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.
