Over a million developers have joined DZone.

Software Design: Simplistic or Optimal

DZone's Guide to

Software Design: Simplistic or Optimal

· Performance Zone ·
Free Resource

Built by operators for operators, the Sensu monitoring event pipeline empowers businesses to automate their monitoring workflows and gain deep visibility into their multi-cloud environments. Get started for free today.

"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.

Download our guide to mitigating alert fatigue, with real-world tips on automating remediation and triage from an IT veteran.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}