Category: Softwares

Good ideas kill projects. Sometimes it’s a quick death, but often it’s a slow, lingering death caused by missed milestones and a spiraling bug count.

You know the kinds of good ideas I’m talking about: Tempting, no-brainer, innocent-looking, couldn’t-possibly-hurt-to-try sorts of ideas. They usually occur to someone on the team about halfway through a project when everything seems to be going fine. Stories and tasks are getting knocked off at a good pace, initial testing is going well, and the rollout date looks solid. Life is good.

Someone has a “good idea,” you acquiesce, and suddenly you are re-fitting a new version of Hibernate into your project to take advantage of the latest features, or implementing AJAX in some of your web pages because the developer showed the user how cool it is, or even re-visiting the database design to utilize XML features of the RDBMS. You tell the project manager you need a few weeks to implement this “good idea,” but it ends up impacting more code than originally anticipated, and your schedule starts to slip. Plus, by letting in the first “good idea,” you’ve allowed the proverbial camel’s nose in the tent, and soon the good ideas are coming out of the woodwork and it becomes harder to say no (and the camel is soon sleeping in your bed).

The really insidious thing about “good ideas” is that they are “good.” Everyone can recognize and reject “bad” ideas out of hand – It’s the good ones that slip through and cause trouble with scope, complexity, and sheer wasted effort incorporating something into the application that isn’t necessary to meet the business need.

Here are some key phrases to look for:

• “Wouldn’t it be cool if …” Really, any sentence with the word “cool” in it is a danger signal.
• “Hey, they just released version XXX of the YYY framework. We ought to upgrade!”
• “You know, we really should re-factor XXX as long as we are working on ZZZ …”
• “That XXX technology is really powerful! Maybe we could use it on …”
• “Hey, <yournamehere>, I’ve been thinking about the design and I have an idea!”

Okay, okay, maybe I’m being a bit too cynical with that last one. But keep watching out for “good ideas” that can kill your project.

Software designers, and architects in particular, tend to evaluate solutions by how elegant and optimum they are for a given problem. Like judges at a beauty contest, we look at a design or implementation and immediately see minor flaws or warts that could be eliminated with just a few more changes or re-factoring iterations. Domain models simply beg for one more pass to see if there are any common attributes or functions that can be moved into base classes. Services duplicated in multiple implementations cry out their need to become web services. Queries complain about “buffer gets” and non-unique indexes and demand attention.

My advice: Don’t give in to the temptation to make your design, or your implementation, perfect! Aim for “good enough” and stop when you’ve achieved it.

What exactly is “good enough,” you might ask? Good enough means that the remaining imperfections do not impact system functionality, maintainability, or performance in any meaningful way. The architecture and design hangs together. The implementation works and meets the performance requirements. Code is clear, concise, and well-documented. Could it be better? Sure, but it is good enough, so stop. Declare victory and move on to the next task.

The search for perfection in design and implementation leads, in my opinion, to over-designed and obfuscated solutions that are, in the end, harder to maintain.

A number of the axioms in this book caution designers to avoid unnecessary abstraction or complexity. Why do we have problems keeping things simple? Because we are seeking the perfect solution! Why else would an architect introduce complexity in a workable solution except to address a perceived imperfection in the simpler design.

Remember that application development is not a beauty contest, so stop looking for flaws and wasting time chasing perfection.