My Biggest Fear as a Developer…
…is that 5 years from now, some other developer will be cursing my name for something that I did. (They may not actually know my name, but they’ll be cursing what they imagine it is.)
That something I built, or some decision that I made, went on to become set in stone and now is making their life more difficult. That something wrongly optimized, or just poorly done, is now actively hindering future progress.
Of course, none of us can predict the future, so this is basically unavoidable. Conditions always change, so what I’m optimizing for now is almost guaranteed to become the wrong thing at some point down the road.
So developers are always going to be cursing my name, at least a little bit. But how can we try to reduce this?
1. Seek out as many perspectives as possible.
When you’re doing something that could have big implications down the road, make an effort to get lots of feedback from people from different backgrounds and perspectives. (And then listen to their criticism and be willing to change your ideas – which can be difficult, I know.) Every person brings their own angle to a problem, and each angle can see different holes and cracks.
You need a panel of trusted experts who you can call on regularly, to vet ideas and tell you when you’re being dumb.
It helps to find people who will:
a) not play politics with your ideas, but evaluate them strictly on merit,
b) keep it constructive, and
c) give you honest criticism without holding back.
Chances are if you can get a whole group of designers and developers to agree that something is okay, it’ll stand the test of time a whole lot better.
2. Don’t overdesign.
There’s this great William Gibson quote that I absolutely love:
“That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace.”
Design for grace. Make the bare minimum number of decisions required to meet the current need, and make those decisions easy to change. Leave daylight between every part of your system and every other.
There are a million different patterns around to help you do that. Use them, but don’t overuse them, and remember also that a lot of design patterns introduce complexity.
In the tradeoff between simplicity and flexibility, lean toward simplicity, so that other people can understand your system. Don’t try to anticipate future needs – you’ll get it wrong. Instead, create a simple and solid foundation so that future needs can be met by future developers.
Another quote that I love, from Antoine de Saint-Exupéry:
“Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away.”
3. Draw on principles from information architecture and usability to make your system sensible.
As developers, we’re lucky because we design for other developers. In a very real sense we are our users. But we’re still never exactly our users, and the view of a project when you’re eyeballs-deep in code is different from that of someone faced with learning to use a system from scratch.
Consider the basic principles of usability as they apply to code design. Develop sensible hierarchies. Use agreed-upon domain terminology when naming methods and variables. Design your API, don’t just let it evolve blindly. And yes, this is where the dreaded task of writing documentation comes in as well.
(I may be the only developer in the world who actually enjoys creating documentation. But I like writing and teaching and psychology, and creating good documentation draws on all of these. I find it an interesting challenge.)
I think that learning a few basics of IA, design, and usability will make anyone a better software architect, because it trains you to effectively consider another person’s point of view.
In the spirit of #1, what am I wrong about? What other things can we do to help our code adapt to future change?