Keep It Simple Stupid (KISS) has been around for a while and didn’t originate in software engineering. There are several variations that replace the word “stupid”, people tend not to like being called stupid, but none of them say it as well as just Keep It Simple. I’m also going include about the related concept, You Aren’t Gonna Need It (YAGNI). I tend not to think in acronyms but they get thrown about so lets have a look.
On the face of It KISS makes sense. If you’ve got the choice between a simple option and a complicated option then, everything else being equal, the simple one is probably better. It’s probably faster to produce, understand, debug, document, everything. However, everything else is often not equal.
I think one of the big problems that happens is context. Say, you have a choice between creating an class that is easy to write but hard to use or hard to write but easy to use. You might choose to Keep It Simple and write the class in easy way. However that’s going to condemn everyone who uses it later to extra work. If I were weighing things up I’d try to consider how much use this class it going get. If the use case is fairly specialised then time invested now won’t be made back in the future, so keep the internals simple. If the use case is common then time invested now will be paid back with interest, so keep the externals simple.
No-one can really predict the future, only make educated guess. So that’s what thinking about these use cases has to be. YAGNI comes from the extreme programming movement. It would encourage you do go for simple internals now and let the future worry about itself. Given my goal of balancing things this seems to be a poor choice. I was ready to throw myself against it. However extreme programming is also meant to be used with other practices such as continuous refactoring, automated unit testing and continuous integration. I think it would be fine to go with the simplest possible option… but only if you’re willing and able to throw it away and refactor as soon as needed. Unfortunately I don’t think most teams have the time to take this approach and trying to balance thing now is better.
Being ready for change
In my experience the thing you should expect in the long term is change. It could be that your project isn’t well specified at the moment. It could be that market conditions are changing and so project goals have to shift as well. It could be that a system that you planned to use has problems and you have to pivot to something else. However you think your class might be used you can’t be sure. I think you should be wary of an option that boxes you in to a corner. Whether that’s spending lots of time now to make the internals simple or potential wasting a lot of time later if the externals were simple.
There’s a specific example that I haven’t experienced myself but have heard about several times. Writing a video game for one language is easier than worrying about multiple translations. However if the situation changes late in development retrofitting a game to work with multiple languages can be a lot of work. It might not be practical at all. Writing a video game for one language but with an allowance for multiple languages is only a small amount of extra work. Having gone through retrofitting hell once developers may be happy to put a little bit of extra effort in just in case. If there’s a large potential cost in the future then it can make sense to invest now to reduce it.
I am often willing to invest time now in order to save time later on. However if time is scarce now then it might still be worthwhile to invest a little bit of time now in order to get flexibility later on. Adding a few light weight intermediate classes and functions to wrap up concepts that might become more significant later on. Even if the implementation of these is minimal they can give you leverage to make the changes more easily. For the translation example you might pass round a TextMessage class rather than a std::string directly. That makes it easy to search for if you want to update or even remove it later on. If you start passing round a simple std::string then it will be indistinguishable from any other std::string. It may require a few extra functions that understand TextMessage rather than std::string but they can be very simple functions.
If you want to Keep It Simple be ready to think about simplicity both now and in the future. The longer and more extensively code is going to be used the more beneficial it is to invest in it early on. Even if you can’t take the time to invest in the internals of a system try to invest time in the interface. A good interface can used easily in the future and the bad internals of a system can be improved without disturbing the rest of the codebase.
Leave a Reply