Performance Zone is brought to you in partnership with:

Developer with experience in a variety of different systems and technologies, with a customer focus and balance with business goals. Particularly interested in backend and large scale systems, and also interested in high level architecture, and API design. Always open to feedback in order to keep learning and improving as a professional. Rodrigo is a DZone MVB and is not an employee of DZone and has posted 39 posts at DZone. You can read more from them at their website. View Full User Profile

Software Design: Simplistic or Optimal

10.29.2012
| 5017 views |
  • submit to reddit
"It is hard for other people to give up on the notion of design simplicity. For example, the notion of simple design is espoused in some of the new methodologies, such as Extreme Programming (XP) and Agile Development (AD) (they suggest seeking the simplest design solution that could possibly work). Certainly, for some kinds of very simple problems the design probably can be made simple. But for problems of substance, the XP/AD approaches harbor serious dangers." - Robert Glass, "Facts and Fallacies of Software Engineering"
 
This quote hits home. Recently I've worked on a high-level design for a problem and, while a challenging problem from technical, I noticed how much people think differently about designs. Not only from this recent experience, but from other experiences, I can see the designers leaning towards XP/AD approaches, where one just take the requirements at hand and solve the problem. The main point is that you can't anticipate the future and things change, from business priorities to technologies, so it's very likely that you will scrap that design and do something different anyway. With that in mind, why overengineer the solution?  
"Missing requirements are the hardest requirements errors to correct." - Robert Glass, "Facts and Fallacies of Software Engineering"
 
This other quote also hits home. In the rush to get some designs done - who can wait for the requirements to be clarified? - there's a tendency to go with a solution that satisfies the known requirements. By not going the extra mile and trying to find out the direction the company is going into and taking that into account, you take the risk of moving on with a solution that cannot be reused with the requirements that could have been uncovered and taken into consideration. One important point, though, is that there are various levels of design decisions that one can be made. Whether you go with data store A or B can have a significant impact and be very hard to change later without a major rebuild of the software. Making a wrong low-level design, while also having some cost to redo and improve, can be much more isolated and manageable.

 
"[...] that leaves us with the notion of optimal design. There are a few people who believe in seeking and achieving optimal design, particularly those who espouse scientific approaches to the problems of business applications (for example, so-called management scientists). But all too often those optimality-seeking scientific approaches work only for a vastly simplified version of the real problem being undertaken. In those circumstances, a solution may, in fact, be optimal but at the same time be useless." - Robert Glass, "Facts and Fallacies of Software Engineering"
 
The other extreme takes place when an "optimal" solution is attempted. Better to quote Glass again, "For complex processes, we learned from Simon (1981) that optimal design is usually not possible, and we must strive instead for what Simon calls a 'satisficing' solution. Satisficing (rather than optimizing) solutions are those that can be seen to satisfy enough of the criteria for a good design that it is worth taking the risk of choosing that approach and proceeding with problem solution, given that an optimal design is likely to be either impossible or not cost-effective to find." I've seen that happening as well, and either the designer never gets anywhere, or it's cut short in the interest of time and design turns out to be worse than if a more pragmatic solution had been attempted.

Ideally we'd like to take a pragmatic approach from the hardest design problems and try to clarify requirements along the way. Definition of "hardest" and critical requirements is a judgment call are among the things that will depend quite a lot on the designer's experience. Also the experience will help decide what is to be left aside or deprioritized, as well not designed at all at a high-level - and left to the coder to work on this design.

Overdesigning a solution where the coder doesn't make any decision and does not exercise creativity is another point that must be avoided. The line where one may be missing important design aspects and where one is overdesigning is blurry, and top designers tend to know where it lies.
Published at DZone with permission of Rodrigo De Castro, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Sat, 2012/11/03 - 11:54pm

The risk from being overconfident and trusting and putting too much time and faith in the current requirements and detailed design is that it will be precise at a low level but inaccurate at a higher level, which will make it much more difficult to remove and redesign as soon as you become aware of the mistake.  This is very wasteful to say the least.

It is less risky to try and build core functionality that is modular and loosely coupled so requirements (and to some extent design) changes will be isolated and have minimal impact, and then add additional functionality iteratively.  The sooner you run into problems the less costly it will be to correct, but don't guarantee lots of problems by proudly assuming what you don't really know up front.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.