Keep It Simple
"Everything should be made as simple as possible, but no simpler." -Albert Eistein.
For any developer (or any tradesman for that matter), good habits and sharp skills require a solid foundation. For me, that foundation came from my course work at Bay Path Regional Vocational Technical High School. One of my instructors there, Bill Bostock, the very first day of class, wrote on the chalk board in large letters:
K.I.S.S.
Then asked us what it meant. After some giggling and music references, he elaborated:
Keep It Simple Stupid
The KISS Principle
That day and that lecture will stick in my mind for ever. I even use it in my own introduction to computer programming lectures at American Career Institute. He told us there are many answers to any given problem, some complex, some simple...do everyone a favor, and pick the simple answer, stupid. He was never one for political correctness.The KISS Principle states that systems run better if they are more simple and less complex, therefor simplicity should be the goal in any design. Let me say that again...
Simplicity should be the goal in any design.
I apologize for the exclaimation... I'm ranting. However, it is a key concept, and if you get anything out of this article, I want it to be that.
The credit is given to Clarence "Kelly" Johnson for coining the phrase, though there is a little lost in translation over time. He was referring to the need for repairs to the planes he and his team were designing/building to be able to be performed by the average mechanic with simple, basic tools, and for those repairs to be made quickly. Keeping the design/engineering simple, allowed them to be repaired quickly by the average mechanic with the basic tools in any tool box. So we should really say: Keep it simple and stupid. This applies to software engineering just as well as mechanical engineering. Make sure your design and code implementation can be read, understood, and maintained by the "average" developer.
The Average Developer
Hummm... the average developer. What is the "average" developer? What does that skill set look like? Let's turn to our colleagues at Construx, Inc, and take a look at their Professional Software Engineering Pyramid. Their research shows that of the 3,000,000 developers in the USA, only 10% of developers occasionally read trade material and/or make an effort to sharpen their skill set, while the bottom 80% aren't doing anything but showing up to work. Wow. Ok... deep breath and step back... so the "average" or "typical" developer only knows what they were initially taught (rather what they retained), and what they may have picked up by osmosis on their projects. For this group, the quality of the experience is a critical factor. Based on my experiences over the last decade or so, I have to agree with their research. I've seen developers with 10+ years experience with no more knowledge and skill than an entry level developer with 1 year experience (in some cases less... scary). Some of the worse code I've ever reviewed was written by "senior" engineers. This is not isolated to developers. As a paramedic, I met EMT's and Doctors with 20 years experience who I would not trust with my dog, let alone a sick patient. As Construx points out, it's not the number of years, but what you do with those years that makes you a senior engineer... but that's another rant, err, topic.Back to keeping it simple and stupid....
So, what we learn from Contrux is odds are very good that your design and your code will be implemented, maintained, and supported by someone with a basic understanding of simple coding constructs (basic tools). I have to give kudos to Microsoft. They realized decades ago that the average developer will be that bottom 80% of the pyramid, with basic to intermediate skills, but with a good working knowledge of the business rules. They have done a tremendous job at pushing the complex stuff deep into frameworks and tools, and providing the developer with very simple API's and tools, allowing him/her to implement even the more complex business rules with simple, easy to understand constructs.
The Coolness Factor
All to often I see developers purposely (or even subconsciously) make something overly complex that really is very simple. My only explanation for this (and many colleagues concur) is what I call "The Coolness Factor"... "if I write complex code, it will be really cool and make me look smarter".Story time...
Back in Mr. Bostock's class, we had lots of term papers to write. A fellow student found the thesaurus feature in WordStar to be "cool". So, to make himself look smart, he used the thesaurus throughout the entire paper, trying to find the most sophisticated or "coolest" synonym for the simple words he already knew. What he ended up with was a literary abomination that made no sense at all, and an "F" for a grade. Anyone of the average 10th grade education level couldn't understand what they were reading, and the teachers who knew the real meanings and proper usage of the words, found it comical but appalling at the same time. In trying to be cool and sophisticated, my classmate only succeeded in being the class dunce.
I see the same thing in code all the time. Developers using more complex approaches and/or the wrong technology/approach because it's "cool", and all they succeed in doing is creating a system that cannot be understood by other developers at the same or lower level, and horrifies the senior developers who can read/understand it because the usage is wrong and is creating more problems with the system than value. For example, take the following C# code:
public int GetTotalMilliseconds(TimeSpan time)
{
int hours = time.Hours * 3600 * 1000;
int minutes = time.Minutes * 60 * 1000;
int seconds = time.Seconds * 1000;
return time.Milliseconds + hours + minutes + seconds;
}
All the developer really needed to do was call...
time.TotalMilliseconds;
...in place of the custom method. Sure, it's way cooler and more fun to write your own routine, but why? Where is the value in hand-rolling your own method for this? Answer: NONE. This code adds no value what so ever, in fact, all it succeeds in doing is adding at least 9 stack frames, 3 stack variables, extra CPU cycles, more work for the garbage collector, an increased potential for bugs, the need for an additional unit test, and an annoyance when stepping through the debugger.
Value
A colleague of mine, Harry John, put it perfectly... If any construct is going to be added, it must add value to the system. Re-inventing the wheel never adds value. When considering an approach, ask yourself, "Is there any value in this?" If there is no value in using a factory pattern, don't. If there is no value is creating threads, don't. If there is no value in abstracting business logic 6 layers deep, don't. If there is no value in re-inventing the messaging layer in WCF because working with SOAP messages is cool, don't.A valuable commodity in any project is time. Adding unnecessary complexity to a design or code implementation adds unnecessary coding time to the project, as well as more time to unit test, debug, fix, and enhance the product. Keeping the design and code implementation simple will make developers more efficient, and if you're an Agile or SCRUM shop, add more velocity.
Conclusion
Keeping it simple and stupid:- Saves time
- Increases developer productivity
- Decreases the potential for bugs
- Improves the stability of the system
- Increases the maintainability of the code
- Wastes Time
- Decreases developer productivity
- Increases the potential for bugs
- Decreases the stability of a system
- Decreases the maintainability of a system
So keep it simple, keep it stupid, and ask yourself "What is the value?". Your fellow developers will thank you for it, your code will be of higher quality, and your use of time more efficient.
Comments
Post a Comment