Keep it simple...
I just returned from a week camping in the desert. One thing that this burned into my head (while the sun burned into my anglo-saxon skin) was the importance of keeping things simple. As a software developer, I am often reminded of this, but in less brutal ways. Somehow, watching the desert winds rip tarps to shreds, bend metal, and mutilate PVC pipes... is all more impressive than just getting a constant stream of bugs from code you thought finished.
KISS = Keep It Simple Stupid
Keeping it simple, is all about focusing on the core of the problem, not letting the desire for all the bells and whistles distract you. If you get the core problem solved well, then the design will be less cluttered with extra code that limits your ability to rework what is there. The best developers I have worked with all are constantly refactoring code they just wrote (or wrote 6 months ago). They are not rewriting it, they are reworking the logic that is there for better integration with the new features they are adding. For that to work, what is there should be clean and simple enough to understand. That doesn't mean that it is simplistic. That means that local dependencies and expectations are clear and reliable. It means that you can come back to the code in a few months and have a decent hope of knowing how a change will impact the existing functionality.
A lot of people confuse 'simple' with 'simplistic'. Sometimes 'simple' does equate to simplistic, but sometimes it means 'clean' or 'clear'. You can't write a real-world compiler that is 'simplistic', but that doesn't mean you can't apply KISS principles. Applying KISS means having clear boundaries. It means that you add complexity as necessary, in small, easily understood steps. Introduce enough new complexity and you should be refactoring it into small, simpler pieces again.
Part of my job at Microsoft has had me do security reviews of a lot of code. Trying to understand old code, potentially written by someone else, really makes one appreciate developers who truly apply KISS while developing their features. There have been features that I have had to give up on reviewing, just focusing on core code-paths, because I simply can not hold the entire design in my head... tens of mutually dependent state-variables are one give-away. Another is long methods of unbalanced if/else blocks, handling myriads of impenetrable special cases.
The developers who best apply KISS principles are also the most efficient. It may take them longer to get you the first working version, but that version has more functional features, than the version produced by the cowboy hacker in the next office, and the cowboy will spend many more late evenings tracking down yet another corner-case bug, while the KISS developer is working on V2.
KISS = Keep It Simple Stupid
Keeping it simple, is all about focusing on the core of the problem, not letting the desire for all the bells and whistles distract you. If you get the core problem solved well, then the design will be less cluttered with extra code that limits your ability to rework what is there. The best developers I have worked with all are constantly refactoring code they just wrote (or wrote 6 months ago). They are not rewriting it, they are reworking the logic that is there for better integration with the new features they are adding. For that to work, what is there should be clean and simple enough to understand. That doesn't mean that it is simplistic. That means that local dependencies and expectations are clear and reliable. It means that you can come back to the code in a few months and have a decent hope of knowing how a change will impact the existing functionality.
A lot of people confuse 'simple' with 'simplistic'. Sometimes 'simple' does equate to simplistic, but sometimes it means 'clean' or 'clear'. You can't write a real-world compiler that is 'simplistic', but that doesn't mean you can't apply KISS principles. Applying KISS means having clear boundaries. It means that you add complexity as necessary, in small, easily understood steps. Introduce enough new complexity and you should be refactoring it into small, simpler pieces again.
Part of my job at Microsoft has had me do security reviews of a lot of code. Trying to understand old code, potentially written by someone else, really makes one appreciate developers who truly apply KISS while developing their features. There have been features that I have had to give up on reviewing, just focusing on core code-paths, because I simply can not hold the entire design in my head... tens of mutually dependent state-variables are one give-away. Another is long methods of unbalanced if/else blocks, handling myriads of impenetrable special cases.
The developers who best apply KISS principles are also the most efficient. It may take them longer to get you the first working version, but that version has more functional features, than the version produced by the cowboy hacker in the next office, and the cowboy will spend many more late evenings tracking down yet another corner-case bug, while the KISS developer is working on V2.
posted by derek at 10:16 PM
1 Comments:
I've been on this wavelength for a while now:
It really is this simple
Half a product or a half-assed product?
Small is the new big
Good luck in your new job.
Post a Comment
<< Home