This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
May be this post belongs to design forum. But, if there is a module on which a single expert programmer worked and completed in a fast pace, due to delivery contraints. If some one else needs to maintain that module or create similar module he may need details of approach to the original module. Is there a pattern that gives a "Story" of the original module design and implementation. Could that be "Story pattern". You can start saying that proper documentation like design documents, comments on the actual code etc are sufficient. But, what if it is a very complex application and not so easy to comprehend by just looking at the standard documentation. Any thoughts??? Kishore.
The tightly-coded module written by the "expert" developer is a common occurence in software development. I could name several "experts" I would never hire again because of the overwrought, unmaintainable messes they left behind. You make a great point: there is plenty of code out there that has comprehensive design documentation and is liberally commented, yet is completely inscrutable. Given the choice between a well-crafted system with little or no documentation/comments, and a poorly-crafted system with voluminous documentation/comments, the well-crafted system is a far better legacy. Well-crafted means that the system has a clean design and that the code is clear, understandable, and easy to maintain. Cleverness is a liability. Simplicity is a virtue. While there may occasionally be a need for complex logic and code, it's not an excuse to let that happen to the rest of your system. I'll warrant that 98% of the average business system can be simply expressed. Object-oriented development is partly about encapsulating complexity. If you can't eliminate the complexity, at least isolate and contain it. The real solution is to not let it happen. Pairing is one potential solution: at least one other developer should fully understand any portion of the system. Or if you're not willing to pair, hold design and code reviews. If you let an overpriced consultant bang out a lot of code that no one looks at before he or she leaves, you're insane. If your consultant is too expensive or too arrogant to weather peer review, find another consultant to do the work in the first place. Every shop has rules, whether they are written, oral, or inherent in the system. I'm not talking just coding standards, but process standards. If your shop insists on comprehensive unit test coverage, the consultant must produce tests also. Make sure that your pricey consultants follow the rules everyone else does. It may seem expensive to get a clever consultant to dumb themselves down so we can understand their work. But it can be far more expensive (and sometimes impossible) to smarten you and your team up after the clever guy leaves. -Jeff-
Originally posted by Jeff Langr: It may seem expensive to get a clever consultant to dumb themselves down so we can understand their work. But it can be far more expensive (and sometimes impossible) to smarten you and your team up after the clever guy leaves.
I agree, many "experts" are too clever for their own good, much to the detriment of their clients & peers. A good consultant on the other hand probably wouldn't need to dumb down too much--just produce simple and understandable code that clearly shows its intent. There is a limit to which you can simplify things though--was it Einstein who said "Make things as simple as possible, but no simpler."? One thing I would look for from an "expert" would be the unit tests that they used to validate their code. Those can give you a good idea of the thought processes involved in creating the code.