My motto in life is that if you are doing something and it is hard, then you are doing it wrong. I originally started thinking this way when I was figuring out guitar riffs. I would listen to the riff, pick out the notes and find the progression. I would then watch the artist play the riff and adjust the progression so that I could play it as fast as he could. There are so many ways to play the same riff that I could sometimes find faster ways than the original artist.
Later in life I applied the same principle to software and hardware engineering. For any given problem there are a large number of solutions and the more difficult solutions are usually not the best choice. Each individual will approach a design from a different angle and end up with a more or less flexible solution. The trick is to balance flexibility with complexity. Some of the most talented designers that I have known are considered to be poor designers by their peers.
If software is too complicated it is difficult for peers to understand. If too much effort is required to understand something it tends to be discarded and re-written. Oddly enough, it seems that if something is too easy to understand, it is considered to be simplistic and re-written as well. Designers that strive for simple easy to read code can be labeled as minimalists incapable of understanding more complex solutions.
Code reuse is encouraged in today’s R&D organizations and for the most part is a good thing. Once a block of code has been designed and debugged, it becomes a solid building block. The thing that is often ignored with this approach is that an existing block is not always the best fit for a simple problem. I have seen problems that required maybe ten classes be extended to literally hundreds of classes by including inappropriately complex libraries or JAR files.
If the target platform is not resource limited, it is difficult to build a case for keeping solutions simple. We do have to remember that at some point others will have to support what we do. If the complex additions are part of a standard package like Apache, then chances are the next people will already understand what we are doing. If the additions are JAR files than contain hundreds of custom classes that for the most part will not be used….then it’s probably a bad decision.
I commented to one of my friends that “If thing are hard you are doing it wrong” and his response was “Fred, sometimes things are just hard”. I can’t really argue with that statement, but I would suggest to you that hard things as not as common as we might think. I would also like to say that “Simple is not easy” so those people who think that simple solutions are for simple people, you might want to re-think.
I believe in the “Mr. Scott” approach to engineering. You know the captain is going to ask you to do the impossible so be prepared, complain about the unreasonable request and then deliver the solution. Don’t over think the solution and do you best to keep it simple.
One of your better blogs, Fred. I particularly like the last paragraph – I’ve seen you plunge in while others were explaining why the request was impossible. They’d still be explaining why it was impossible when you delivered a working prototype!