When Voltaire wrote, “The perfect is the enemy of the good”, I strongly suspect that he did not have software design and development projects in mind. But he may well have in mind had one of problems that software development projects of often suffer:  elegance creep. When is “good enough” actually better than perfect? What can architects, project managers and business stakeholders do to recognize and address elegance creep?

There are many common causes for software project problems and many methods have been  established to improve development practices. To drive success on our projects, we at Summa have established disciplined practices, methods and processes for our projects around requirements analysis, design, development, testing, peer reviews and deployment on our projects. In addition to selecting the right technologies and prescribing the right architecture, there are also soft aspects to successful project execution that are less concrete: involving users and stakeholders in the vision; capturing/communicating the right level of detail about the requirements and plan at the right time; assessing, communicating and managing project risks, proper education and communication with stakeholders, etc.

But here, I want to cast new light on a another infrequently discussed problem and share some thoughts on how to address it.

Elegance Creep

Project teams often cite feature creep as a root cause for missing project milestones or quality goals, but there is frequently another often subtle and buried phenomena that is a cause: “elegance creep”.  Software projects sometimes founder or fail because team members focus energy on a perfect solution to a problem that does not deserve it or even exist in the first place.

Many times the “elegance” in the design is really the right stuff  – frequently it addresses implied or unwritten non-functional requirements that drive improved maintainability, extensibility, performance, serviceability and/or productivity.  In other cases there is a lack of awareness of better practices that address the real quality requirement and undue creativity results (I am being nice here). While assessing failed projects in the course of launching Summa remediation projects, I have frequently found cases where programmers have built exotic and academically intriguing solutions to problems that don’t really exist (usually in under the guise of addressing an anticipated but never realized performance or extensibility problem.)

What to do?

How do we recognize and address elegance creep in our projects to establish the proper balance of investment in functional vs. non-functional requirements?  How do we insure that quality requirements that we implicitly know are necessary are communicated to allow the cost/benefit trade-offs to be managed? How do we avoid stifling creativity and innovation that are important aspects of project success?   Here are some of my thoughts on how to be purposeful about managing software quality and non-functional requirements:

• Business Value: In business terms, understand and communicate  goals, benefits, costs, trade-offs and risks for addressing non-functional requirements to stakeholders and all members of the team  (e.g. cost of downtime, cost of maintenance, benefits of efficiency, agility,  quality,  sustainability and performance.)  Ideally use  hard ROI metrics for your environment – but often good statistics do not exist and softer benefits must be used.
• Architecture: Establish, document and communicate the rationale for design decisions around the approach for addressing  non-functional requirements. Understand the solution environment and the long term impact of additional complexity that may occur.
• Project Management: Establish and track project plan items and budgets for non-functional aspects of the project. Recognize and address when team members are wandering into unwarranted elegance.
• Implementation: Establish and use industry best practices to address non-functional requirements on projects  (e.g. commercial middleware for improved security/availability and maintainability, open standards and open source frameworks for application design). Also consider establishing processes to capture and communicate known areas for improvement discovered during implementation (e.g. project backlog line items or defects.)
• QA: Treat non-functional requirements like others in the test plan. Include verification of quality attributes of the design in testing.

None of what I outlined here means that we do not / should not have pride in our work or not  focus on quality designs and code – it is just that project success is much more likely if we are purposeful about managing the benefits, costs, budgets, trade-offs and constraints of non-functional requirements in our design and implementation. We should strive to objectively make and support necessary architecture and project trade-off decisions around non-functional requirements in the open.

Be Sociable, Share!

•