Software Philosophy

Overdesign Paradox

 #design   #overdesign   #paradox   #complexity   #quality attributes   #requirements   #good design   #experience   #software 


I recently watched Is TDD Dead hangout, where Kent Beck expressed his opinion about theory of Test-Induced Design Damage. He spoke about poor design decisions and how reaching good design takes time. I believe, that word "overdesign" was not used in the conversation, but it was ringing in my head all the time when I watched it. I also cought myself using word overdesign when speaking about some enterprise framework (version 3.2). I've spent some time thinking about it and it came to me, that this word is used in multiple meanings and may even contradict itself.


This post is a pure mental masturbation. It contains some correct information, but as a whole it does not make much sense. I am very embarrased and I strongy do not recommend reading it.

Measuring Goodness

First impression is that overdesign is something negative and not wanted, therefore it can not be considered a good design. I'll try to sketch some characteristics of good design to narrow the space for overdesign's definition. My understanding is that goodness of software design can be measured by (at least) two factors1.

  1. Satisfied non-functional requirements - Design is all about balancing non-functional traits (quality attributes) of the system. Higher degree of requirement satisfaction means better design.
  2. Complexity - Simple design (containing less elements, less dependencies between elements, less levels of abstractions) is better than complex one.

One could argue that complexity is just an opposite of simplicity, which is also a quality attribute, so it shouldn't be treated separately. True, but simplicity is used in philosophy of science as meta-scientific criterion by which to evaluate competing theories (in current context - competing designs). I think it deserves separate place as some sort of quality meta-attribute. Clever, unobvious solutions that resolves many problems at once are considered less complex, more elegant, better designs.

Complexity is used instead of simplicity for presentation purposes. It enables putting design evaluations on two-dimentional graph in which average designs are located on the diagonal, better designs are above it, and worse are below.

Goodness Graph

Design that keeps complexity low and meets non-functional requirements at acceptable level can be considered good. If overdesign is not a good design, then it must be characterized by high complexity or low level of quality attributes (or both).

Widespread Understanding

In my early days as a software designer I was pretty much obsessed with design patterns. I've had this vision that each line of code should be written according to some known design pattern. I had to memorize all of them and use them in my daily work. The result of such thinking was obvious - I've written much code whose main function was to look pretty and then I've made up silly justifications of what it enables and why is it important...

I was literraly making up requirements for the system after creating a design that satisfied them. I got the impression that people describing my programs as overdesigned were refering to that kind of activity.

Definitions of word overdesign, which can be found in dictionary of construction, wiktionary and meriam-webster dictionary, describe overdesign as design that introduces traits which are not required and result in high complexity. On design goodness graph, overdesign (by this definition) would be located on right-hand side area under the diagonal.

Overdesign vs. Underdesign

Agile-oriented people often view overdesign as too big complexity of the initial design, that results in many subsequent changes as the program evolves. On the other hand, program structure, which is not sophisticated enough to support further development, is often called underdesign.

At first glance those definitions are also connected to satisfying (too much or too little) quality attributes, but they are actually more about bad design decisions. We (software designers) may not have the ability to acurately evaluate our designs if we are not experienced enough. Consequences of bad design come to us later and so does conclusion of too much upfront design.

Intended Overdesign

Experienced designers like to think of overdesign as deliberate effort to make the design more concentratated on particular quality attributes than it is required with the intention of refactoring it later. In many situations this approach is actually the pragmatic way, because simplifying good, complex design is a lot easier than making simple design more complex (and still good). Complex upfront design may also enable easy experimentation with quality attributes.

Overdesign can also mean concentrating design on quality attributes, that have extremely high requirements (overdesign for performance, or securabity, or correctness, etc). This definition does not take the complexity into account. If design is simple in structure but meets high requirements, it is still considered overdesign.

The Paradox

I think word overdesign shouldn't need definition (it should be self-explanatory). Let's try explaining the word by using meanings of its components.

Design is an activity of modeling the system. The activity needs (some form of) requirements as its input. Prefix over- suggests that optimal solution was present in the past, but further design process introduced extra, unwanted design? This is clearly not the case. Over- in overdesign means to too much requirements (or too much complexity), not too much design process.

Lets say that probability of producing so-called overdesigned software is higher when having unexperienced software designers in the team. If overdesign means too much design, does it mean there will be more design in this (overdesigned) software than in software made by experienced designers?

In situation when experienced designers take over the overdesigned program and apply more design process to it, the result may be a program that have good design and will not be overdesigned any more. Does this make sense?


I was able to identify 5 different definitions of overdesign. 3 of them are negative, 2 are positive. This is a good basis for misunderstandings. Using more precise wording (such as overcomplicated, exceeding requirements, concenrated on something) could eliminate the confusion.

Self-explained word overdesign does not make much sense.


Martin Fowler wrote (among other things) about delibarate overdesign in his article titled Is Design Dead. Thoughts of people like Alistair Cockburn and David Thomas on topic of overdesign can be found on Cunningham & Cunningham Wiki.


[1] I intentionally didn't mention cohesion and coupling when writing about good software design. Cohesion and coupling are often used as software design quality metrics, but depending of required quality attributes, high cohesion and low coupling can be desired or unnecessary, therefore they can't be taken into account in the general case. Of the same reason I didn't mention any software design principles.

Maciej Chałapuk

blog comments powered by Disqus