Many years ago I wandered into a friend’s office to ask a few questions. Before I could even say “hi” he told me that the manager wanted him to “dumb down” his code. Turns out a couple of team mates complained that the hid OO framework was too complex to follow. They wanted the framework to be more straightforward. He was very annoyed by this because he felt that developers should rise up to difficult code. To see it as a challenge and an opportunity to grow.

Years later I produced an interesting chunk of code that bullet-proofed a process. I was pulled off to the side by the chief architect and was asked to change the code so that a junior developer work with it. It was a fairly simple compiler for a subset of Java. Writing a compiler is somewhat specialized and there is a lot of foundation code, however, it isn’t in insurmountable tasks when you are only working with a subset.

I pled my case that a junior developer should be able to dig into the code, refer to the JVM specification and write some code without much difficulty. It was a matter of the developer rising up to the challenge of something new rather than running away afraid. This argument made sense to the architect and we moved on.

Sometimes a brilliant design is simply beyond the capacity of the existing development team. For example, it is probably unwise to have a PHP team try to implement a Java flyweight pattern. They may finish and get it all working, but then again it could be just a little too challenging for the first time out. Dumbing down is a good idea when the available team is just too junior to do the work.

Dumbing down is also reasonable if you are not going to be around for very long, like a contractor. There is nothing like trying to figure out a brilliant contractor’s work six months after he has left. It really is difficult and he may be the only person who really understands why he chose the path he did. Keeping it dumb is sometimes better when you aren’t going to be able to share that knowledge later.

Some designs are needlessly complex and can be simplified. Sometimes we engineers get a little focused on the art of software development instead of the craft. Amazing OO designs need to be checked against real world requirements because they may not scale well. Developers working in Hibernate with a complex data model sometimes find themselves losing a lot of processor cycles to converting the model into rows in a table and back again. Note, I’m saying the the model may be too complex, not Hibernate.

Simplification is about reducing a design to make it run well. Dumbing down is about making life easier for the another developer.

I still think about my friend’s issue with dumbing his code down. Its not always easy to tell when the design needs simplification (AKA re-factoring) of if the problem is that the team isn’t bright enough. The one thing I know is that I was junior developer back then and I learned a lot from implementing parts of his design.