My Philosophy
What am I, a guy who writes code or a guy who thinks about stuff?
My philosophy is what I believe sets me apart from the other software creators you may have encountered.
Personally this has been hard won but I share it happily. Over more than 20 years of coding for a living
the biggest impact has been the other coders I have met and worked with, some closer than others.
But by drawing inspiration from the ones I wanted to be more like and learning the lessons of the ones
I did not, some some key points started to emerge. At the heart of everything is pride in my work and
remembering that my work is the code. Everyone expects it to work and the UI to look great, but is the
code nice? Will somebody else understand what I wrote? For that matter, will I understand in a
few months or years?
Nice Code!
So, on to what makes 'nice' code. It could be argued that it is entirely subjective and while I agree
there is certainly an aspect of aesthetics that counts, the real core is clarity of expression.
It is hard to overemphasize the importance of this or how often code writers completely neglect it.
I will go into much more depth about the exact techniques and tools to help achieve this but for
software there are barriers to entry that prevent most people from being able to tell the differece.
I once had an IT manager, bright guy, with a history in code writing but could not understand why I
wanted to rearrange (refactor) the working software. Then he did a presentation about a big project
he had run where he showed the rewiring of a data center at great cost, but easily explained why
it made sense because of all the ongoing maintenance and improvement and how the cost would be
recovered many times over in time saving. I knew I had him then. Even though he was not able to
see the 'tangled' state of the code he was able to understand how being untangled would free us up
going forward.
We can see and understand this
It is not hard for most people to look at the patching in this data closet and to understand why
it makes sense to tidy it up, even though it has a cost because the cost of leaving it is
pretty clear. You can easily see that finding what is wired to what is going to take ages each time
and making changes is bound to be error prone. While the new neat wiring does exactly what the
original cables did functionally, what it now also does is express what it is doing much more clearly.
It can be a lot harder for people to understand the value of clinically clean expression in software
because after all what you are paying for is the way the software looks and runs when it is being used,
right? Well maybe. But when your software code is a tangled mess inside like those cables you had better
hope you never need to have it changed. With custom software this is seldom ever the case because you
need it to change continually to meet the changing needs of your business. My experience and that
backed up by a lot of other research is that a vast amount of time and effort is spent fixing, maintaining
and updating old software and usually with deminishing returns as the code gets more and more tangled.
Can it be any different?
The great majority of software writers I have encountered just assume that this is the way it has to be.
At the most basic level it can be really hard to get past the point where you are just relieved that you
managed to get the computer to do what you (or your customer) wanted. Any further considerations about
the code itself never even enter the mind. But once you start coding with a bigger team more factors are
brought in to play. Suddenly you need to stick to a set of 'coding standards'. Other limitations may also
be imposed and in the best cases even some form of 'code review'.
Despite these efforts much of the time it is assumed that code will atrophy and that over time the system
will become so full of patches, hacks and workarounds that at some point the code becomes no longer economically
viable and a system rewrite or replacement is required. You will variously hear things like "Everybody knows:
Any sotware older the 7 years needs to be replaced".
I simply don't believe this to be the case and have see some of the best software stand the test of time
and the formula for making sure your software can survive is very simple. It does however require disipline
and a level of skill and desire to keep up with the state of the art.
