After ACCU last last Thursday I was in the pub with Bronek Kozicki - and many others. The subject of system re-writes came up. This is a perennial subject, for example have a look at Alan Griffith’s Overload 79 editorial or Tim Penhey’s CVu editorial from the same month.
Recently I’ve been consulting with a company which has a truely awful code base. The developers want to re-write it, naturally. Unfortunately the the code base isn’t the only problem, the company has other problems and matters aren’t helped by Kissinger-esque linkage with other issues. I’m not going to say anything else about them except to say Conway’s Law was clearer than ever.
And its not just software people who stuggle with the question: Is it better to re-wright, or not to re-write? This piece from last week’s FT shows English lawyers and tax authories have the re-write problem.
Bronek sent me a link to Portrait of a Noob by Steve Yegge - not a blogger I read but I’ve been sent several of his posts by people in the past so I know of him. In many ways I find this reminiscent of my own High Church C++ pieces from a few years back. Both pieces point out that quality code is subjective, what you think of as good code in one context is not the same as what you consider in another context. Steve is right to point out that your persepctive on code changes. In particular, as you get older and acquire more experience not only does you coding style change but the way you approach problems changes.
As someone pointed out on Thursday night, you also need to remember Fred Brook’s and the Second System Effect:
‘This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.
The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.’
I’ve long wanted to conduct a little experiment. Take a developer, take a system he developed in the first few years of his life. Wait long enough for him to forget the details, say 10 years. During that time let him learn, gather experience and continue developing systems. Now ask him to make changes to the system from his early years - with all the identify removed of course. My theory is, he will proclaim it unmaintainable and in need of a rewrite.
That is a little unfair actually because one of the things you learn as you get more experience - OK, get older, lets not beat around the bush - is that all systems are maintainable. The other thing you learn is that rewrites usually end in failure.
Our education system has it wrong. At school and college we learn to new write new code. But most developers spend most of their time maintaining old code. Our education trains us to believe a lie, that we write new systems. For the first few years of a graduate engineer’s career he is disappointed, he searches for ‘green field’ development and faced with an old system he throws his arms up - ‘Re-write! We must re-write!’
Not only are young developers sadly disappointed by the state of the world they are a risk. Sometimes people believe them and let the re-write the system. (Believe me, I was once that developer. I persuaded my employer to let me re-write a system. It was a mistake. )
Colleges need to recognise this and start setting assignments were people must maintain code written by others. Systems should be handed from one year to the next for changes.
As a developer gets more experience they learn how to work with existing systems, when to re-write parts and when to work around. The hallmark of an experienced developer is that they do not jump to say ‘Re-write!’ - they can at least present options.
In fact, the hallmark of the best developers is that do work with legacy systems. Anyone can write a new system, we get trained for it in college, its what the books describe, there are few limitations. You can create your own mess, and you usually know your way around your own mess.
But the best developers can work with someone else’s mess and still find gold.
Recently I’ve been consulting with a company which has a truely awful code base. The developers want to re-write it, naturally. Unfortunately the the code base isn’t the only problem, the company has other problems and matters aren’t helped by Kissinger-esque linkage with other issues. I’m not going to say anything else about them except to say Conway’s Law was clearer than ever.
And its not just software people who stuggle with the question: Is it better to re-wright, or not to re-write? This piece from last week’s FT shows English lawyers and tax authories have the re-write problem.
Bronek sent me a link to Portrait of a Noob by Steve Yegge - not a blogger I read but I’ve been sent several of his posts by people in the past so I know of him. In many ways I find this reminiscent of my own High Church C++ pieces from a few years back. Both pieces point out that quality code is subjective, what you think of as good code in one context is not the same as what you consider in another context. Steve is right to point out that your persepctive on code changes. In particular, as you get older and acquire more experience not only does you coding style change but the way you approach problems changes.
As someone pointed out on Thursday night, you also need to remember Fred Brook’s and the Second System Effect:
‘This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.
The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.’
I’ve long wanted to conduct a little experiment. Take a developer, take a system he developed in the first few years of his life. Wait long enough for him to forget the details, say 10 years. During that time let him learn, gather experience and continue developing systems. Now ask him to make changes to the system from his early years - with all the identify removed of course. My theory is, he will proclaim it unmaintainable and in need of a rewrite.
That is a little unfair actually because one of the things you learn as you get more experience - OK, get older, lets not beat around the bush - is that all systems are maintainable. The other thing you learn is that rewrites usually end in failure.
Our education system has it wrong. At school and college we learn to new write new code. But most developers spend most of their time maintaining old code. Our education trains us to believe a lie, that we write new systems. For the first few years of a graduate engineer’s career he is disappointed, he searches for ‘green field’ development and faced with an old system he throws his arms up - ‘Re-write! We must re-write!’
Not only are young developers sadly disappointed by the state of the world they are a risk. Sometimes people believe them and let the re-write the system. (Believe me, I was once that developer. I persuaded my employer to let me re-write a system. It was a mistake. )
Colleges need to recognise this and start setting assignments were people must maintain code written by others. Systems should be handed from one year to the next for changes.
As a developer gets more experience they learn how to work with existing systems, when to re-write parts and when to work around. The hallmark of an experienced developer is that they do not jump to say ‘Re-write!’ - they can at least present options.
In fact, the hallmark of the best developers is that do work with legacy systems. Anyone can write a new system, we get trained for it in college, its what the books describe, there are few limitations. You can create your own mess, and you usually know your way around your own mess.
But the best developers can work with someone else’s mess and still find gold.
I was discussing the re-write problem with a friend of mine a few years ago, and we argued from several perspectives for a while before I came up with what I believed to be the final answer - study and understand the old code well enough to maintain it, and only then do you have the right to re-write it :-)
ReplyDeleteThe basic idea is that since most re-writes are due to programmers simply not taking the time or effort to understand what is there, once they have, if the code is maintainable (often the case), then they will do so, and otherwise they at least have the evidence to argue for a re-write.