One of the most important things to know about any kind of engineering is:
There are some things about the future that you do not know.
Obviously it’d be ideal if we were all-knowing and could perfectly predict every consequence of every decision we’ll ever make. But that’s impossible. In fact, it’s so far from possible that if you predict more than half of the consequences of your engineering decisions, you’re godlike or just really lucky.
Let’s take an example outside of the realm of programming: CDs, which were designed in 1979 to replace cassette tapes as the primary method of listening to music. Who could have predicted that 20 years later, DVDs would be made the same size and shape so that manufacturers could make CD/DVD drives for computers? Did anybody imagine the problems of spinning a CD fifty times faster than it was supposed to be spun, for reading in a CD-ROM drive?
This is why, in engineering, we have “guiding principles.” There are certain rules that, when we follow them, keep things working well no matter what happens in the future.
In the case of software, I’ve summed up the most basic guiding principles as the Laws Of Software. The very first (and most important) law is that the future is more important than the present (because it’s very big and the present is very small). But here’s the thing to know about that: that doesn’t mean you have to predict everything about the future. Instead, it explains why you should be making decisions according to the laws of software–because those laws make for good future software, no matter what that future is.
Sometimes it can be hard to understand why you should be stupid, dumb simple, if you’re only thinking about the present. And it can be impossible to predict exactly why or how simplicity will help you in the future. I can tell you that it will help, and you’ll be glad you did it, and if you don’t believe me (which you are welcome to do–your mind is yours!) you’re going to end up in mess of trouble somewhere down the line, in a future you can’t predict.
I’m not singling you out, here. You’re not dumb. It’s just that nobody can predict the total future of a piece of software, except to know that certain decisions now will make that future better, and that other decisions will make that future worse. We know this from decades of experience in the software development industry–certain basic principles invariably lead us in the right direction, and certain “anti-patterns“, if followed consistently, invariably lead us into trouble.
To be a successful software developer, you have to be willing to not know some things about the future, and trust that following your principles is the right thing to do. Sometimes it can take years to see that you were right, but it’s a glorious day when you finally realize that your product still exists because you made the right decision three years ago, when you couldn’t even prove to anybody that it was the right decision, but forged ahead anyway with your “excessive simplicity” because you knew it was the right thing to do.
Methinks that all of this would apply equally well to finance. A little off-topic perhaps but I think it is high time for finance to become more of an engineering discipline (complete with silly things like fail safes, redundancies, personal liability, …) than the current gambling free-for-all that we have now. Engineers learned their lessons through years of death and destruction; programmers are starting to learn their lessons through years of destruction (and maybe a little death); finance has been around longer than both and has caused more death and destruction than both combined but it is still based on little more than hope and delusion.
Wow, yeah, that’s a really interesting thing to think about!
[…] – bookmarked by 2 members originally found by leesz on 2008-08-21 Code Simplicity: Unforseeable Consequences: Why We Have Principles http://www.codesimplicity.com/archives/32 – bookmarked by 4 members originally found by […]
The problem is when your principles work for 99% of the situations, but backfire for the other 1%.
The good news is that you are likely working in the 99%
Well, my hope is that the principles that I’m evolving here actually cover both that 99% and that 1% situation. That is, the idea is that the general principles can’t be too specific, or there’s going to be some situation in which they fail. The important thing is to have good general principles that apply to all situations (by virtue of being natural laws, ideally) and then use your judgment on how to apply them in the practical situations you find yourself in.