Good Design is not Subjective

In case you haven’t guessed by my recent flurry of posts, I’ve been engaged in some debates in the past few days about design philosophies and why some designs are “good” and some are “bad.”  I’ve been met with some relativistic arguments that no design is either good or bad, it just succeeds or fails differently, etc (ok, they didn’t really say that, but that was the gist of the argument).  Of course arguments of relativism are always wrong in my book (it’s usually just that we haven’t reached a level of understanding and specificity in the subject matter to determine EXACTLY why something is A or B).

Well, at least in the subject of design, we actually DO have material and research that points to what constitutes a GOOD design and a BAD design. In fact, it was written over 10 years ago (1996/1997).  Interestingly enough, it rings as true today as it ever did.

What is Bad Design?

First, what is a BAD design?  Courtesy of Robert C. Martin from his paper on the “Dependency Inversion Principal” (PDF link, sorry – emphasis mine):

But there is one set of criteria that I think all engineers will agree with. A piece of software that fulfills its requirements and yet exhibits any or all of the following three
traits has a bad design.

  1. It is hard to change because every change affects too many other parts of the system. (Rigidity)
  2. When you make a change, unexpected parts of the system break. (Fragility)
  3. It is hard to reuse in another application because it cannot be disentangled from
    the current application. (Immobility)

Moreover, it would be difficult to demonstrate that a piece of software that exhibits
none of those traits, i.e. it is flexible, robust, and reusable, and that also fulfills all its
requirements, has a bad design. Thus, we can use these three traits as a way to unambiguously decide if a design is ‘good’ or ‘bad’.

Rigidity, Fragility, and Immobility are qualities of a bad design.  These are problems that will rear their head later during future enhancement or maintenance of the software. Each of these qualities has a corresponding negative real-world impact on the ability to enhance or maintain the software going forward.

Fortunately, there are contradictory and counter-acting practices that result in good traits and qualities of GOOD design.  These include all the good ‘ilities’ like “reversibility’”, “reusability”, “maintainability”, “extensibility”, “portability”, etc.

But it Works!

I hear this argument a lot. It goes something like, “who are you to judge my design because it WORKS!”  “Works” ends up being the relative word and the point of debate. We have different definitions of “works” apparently.  For me, “works” is more than just “fulfills its requirements” (see emphasis in the Martin quote above).  A design can fulfill its CURRENT requirements, but fail miserably in its ability to accommodate FUTURE requirements.  How many of you out there write systems that are NEVER touched again once they are deployed to production?  No hands? I thought so.  Maintainability is IMPORTANT and justifies forethought and strong consideration in any design. If not, you’ll end up with a Rigid, Fragile, and Immobile design and you have just stiffed your employer for a lot of money in future maintenance.  We can do better, and we should!

Conclusion

Good design is not subjective. It is objective. It exhibits properties of high cohesion and loose coupling. Through these fundamental properties, all the other good “ilities” flow and the bad “ilities” are kept at bay.

P.S. – those who know me know that I’m not a big fan of the abuse** of TypeMock’s exotic features (ability to mock anything by twiddling bits under the skirt of the CLR).  The reason I’m not a big fan is because people abuse it in order to get around having to learn and use core fundamental design principles and they can easily end up with a design that has one or all three of the bad “ilities”. Particularly they could end up with a bad case of the “Immobility” trait since they likely didn’t follow the Dependency Inversion Principle (since TypeMock allows them to get away without needing it in many cases).

 

** Note I said ABUSE. I still maintain that TypeMock is a handy tool in general (it’s a good mocking framework) and extra-handy when you’re in an otherwise unmaintainable situation (i.e. SharePoint development). But it’s special powers can be used to get away with things that are supposed to be difficult in .NET (basic OO design stuff).

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in Design. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://colinjack.blogspot.com Colin Jack

    “I’ve been met with some relativistic arguments that no design is either good or bad, it just succeeds or fails differently, etc (ok, they didn’t really say that, but that was the gist of the argument)”

    Are these discussions the ones on twitter or something else? I’m going to assume some of it is based on the twitter ones which influences my reply…

    On first reading this post perpetuates the assumptuon that anyone who questions any aspect of design for testability can’t have read/understood Robert Martin. This seems to happen quite a lot in ALT.NET so I tried to point that out in Twitter and (in the past) on the ALT.NET forum because I think its an unhealthy way to view things. Anyway just to be clear I have read Robert Martin and I do consider the principles important.

    Where do I differ from your viewpoint. I would say that I think there are many good designs available in each situation but that does not mean that I would go for the “bag design” in Robert Martins example, or would look to design SharePoint the way it was designed. I am saying that if you are going to use design for testability then do a good job of it, including using role interfaces.

    I am also saying that in practice design for testability can be overhyped and that the process is over-simplified by many who describe it (create a repository, extract an interface). Personally I prefer to focus on the clarity of the resulting design rather than the extensibility when talking about the average LOB app. Why, because in most LOB apps most of the extensibility doesn’t get used and the IFooService interfaces don’t help because the FooService class itself is simple and cohesive (and that doesn’t mean I don’t think OCP is useful).

    I do find the whole idea that we shouldn’t question these things interesting though, even the biggest Robert Martin fans I’ve met have been able to question some of his work and that’s healthy. I personally find that there is always a healthy middle ground, I don’t slavishly follow the advice in Robert Martins book any more than I do the advice from Eric Evans and Martin Fowler. You always need to make judgement calls.

  • http://colinjack.blogspot.com Colin Jack

    “bag design” == “bad design” :)

  • Maxim

    Actually… the only place in the software industry where code barely change is when you have C code in pieces of hardware. Those… don’t change a lot but they sure as hell work.

  • http://weblogs.asp.net/nleghari Nauman Leghari

    One of the things we did internally is to repeat the ugly code vs clean code session (AgileXP 2008) as a coding dojo session. I must say it proved really helpful in understanding the differences and I do recommend that every software shop should do such session. Fortunately the source code is available at http://code.google.com/p/ugly-and-clean-tictactoe/ but it is in Java so you probably need to use Eclipse. More information here http://patrickwilsonwelsh.com/?p=29.

  • http://www.blogcoward.com jdn

    Except that there is no generally accepted scale to measure Rigidity, Fragility, and Immobility in a precise fashion. You can tell the extreme cases (A is much less rigid than B), but when you get to complicated cases (think of chosing from the different flavors of MVP), you have to take into account a lot of things that ‘feel’ subjective.

    Plus there is a difference between ‘relative’ and ‘subjective’ but that’s a longer story.

  • http://colinjack.blogspot.com Colin Jack

    “I hear this argument a lot. It goes something like, “who are you to judge my design because it WORKS!” …and… “Maintainability is IMPORTANT”

    Just to check, are you saying this is what you think myself and others were talking about on Twitter?

  • http://Bryan.ReynoldsLive.com Bryan Reynolds
  • http://colinjack.blogspot.com Colin Jack

    @jdn
    “Except that there is no generally accepted scale to measure Rigidity, Fragility, and Immobility in a precise fashion”

    Agreed but Robert Martin does describe other principles that you should look at e.g. Stable Abstractions Principle (SAP). A component is stable if it has lots of dependencies on it and the principle indicates that stable (hard to change) components should be as abstract as possible. A quote:

    “It says that a stable component should also be abstract so that its stability does not prevent it from being extended. On the other hand, it says that an instable component should be concrete, since its instability allows the concrete code within it to be easily changed.”

    Thats a direct quote from Robert Martin himself, and it matches my views. I choose not to evaluate, either using the metrics or my brain, the stability of a class before deciding how abstract to make it (mind you wanting to stick it in a container or mock it upfront affects my decision making in a lot of cases).

    Anyway NDepend uses some of these metrics (good luck with the GUI though) but a lot of it is common sense. Read the book if you haven’t though, its very good stuff.

  • Kyle

    My boss has a very, very humorous argument against ALL the books that talk about design: They don’t usually take into account the timeframe required to get the product out the door! That means that they’re wrong (according to him). It embarrasses me to work for that boss, the one who has no clue how to design a program.

    Thank you for writing this article, Chad. I will be sending it to my boss, and possibly the rest of my company, as they don’t seem to understand these fundamental things, and I think you said it very well.

  • http://theruntime.com/blogs/jacob/Default.aspx Jacob

    Good post. Clear and to the point. I disagree, but it turns out my point of contention is as much with the base assumption shared by Martin and others and it really is about defining “Good Design”. And it’s not about relativism, it’s about relevance. You see, what Martin and many (most?) of the Alt.Net folks are missing is that Good Design as defined here is functionally irrelevant. It’s an artifact of silicon-tower development.

    You see, the real world is messy and all kinds of things exist that can legitimately interfere with design. For one, I’ll raise my hand as having half a dozen apps in production RIGHT NOW that I haven’t had to touch since deploying them. And I’m only counting those that have been there for a year or longer (some of them a lot longer).

    What it comes down to is that the assumption of software development homogeneity at the heart of many of the declarations of absolute value are illusory at best. Things that are extremely important in a highly-integrated enterprise simply aren’t as vital in a small in-house dev shop where time to deployment is critical. Just as development for a software tools company is substantially different from development in a specialized chip manufactory.

  • http://theruntime.com/blogs/jacob/Default.aspx Jacob

    @Kyle: Your boss should be embarrassed to have you admitting your ignorance in public. The point of software development is to meet the needs of our users. Those needs include time to delivery as well as functionality. Delivering a highly maintainable piece of crap after its utility has been and gone isn’t going to save you when your users start hunting for the pitchforks…

  • Kyle

    Both my customers and my personal preference is to deliver an application slightly later having a good design than having a shoddy design on time.

    If you’re claim is that time to deployment is more important than the quality of the design, then why are you even in this industry?

  • http://colinjack.blogspot.com Colin Jack

    Not saying I agree with Jacob or not but…

    @Kyle
    “If you’re claim is that time to deployment is more important than the quality of the design, then why are you even in this industry?”

    I don’t think anyone who brings up time to deployment is a hacker who should leave the industry. Also to be clear I don’t think Jacob said that it was MORE important, its just another factory:

    http://tech.groups.yahoo.com/group/altdotnet/message/11674

    Also not sure “shoddy design on time” helps either, no need for the charged terminology or the attacks on peoples professionalism.

  • Kyle

    My apologies, Jacob. I took offense at your tone and went off the deep end, due to working on a project that meets neither of the criteria above – it is neither elegant, nor on time. :)

    I also did not mean to imply that your design(s) were shoddy – that was purely based on the design that I’m forced to work in again, which is the one my boss created, which is why we cannot have this project done on time.

    To be fair, I do think you put a lot of words into my mouth, which is partly why I was offended. I understand where you’re coming from, though, Jacob, having gone to your blog and saw the TechEd meeting post you talked about. I largely disagreed with Billy Hollis, I think his name was, but I didn’t fully agree with the others, either. Mainly, I think it’s best to code with these principles in mind, because they don’t largely affect the total time to deployment; if anything, in my experience, they have greatly decreased that time, due to being able to change things later and flexibly due to a solid design. Whereas the current design I’m forced to work in prevents me from changing any part of it, so it’s increasing the time to deployment pretty significantly.

    Thanks for pointing out my crappy wording, Colin (seriously). Again, sorry for the lash out.

  • http://chadmyers.lostechies.com Chad Myers

    @Jacob:

    Don’t be an ass. All of us make a living in the real world. Just because you don’t grasp basic design concepts and are content with bashing DIP ignorantly doesn’t mean that the rest of us are ivory/silicon tower.

    You’re insults are embarrassing to everyone. Don’t just bash, be specific and give examples. Your posts are dangerously close to blog bile and contribute very little, if nothing other than to just be insulting and dismissive.

  • http://chadmyers.lostechies.com Chad Myers

    @Colin, Jacob:

    People like Kyle and myself wouldn’t be employed if we didn’t deliver projects on time and exceed customer expectations. Kyle wouldn’t be able to live the lifestyle he does if he wasn’t fantastic at what he does.

    But we’ve worked with and for numerous environments where there were people like Jacob arguing silly arguments about Design vs. Time-to-Market and then producing horrific code that falls on its face soon after said deployment. They then proceed to make all sorts of excuses and blame everyone but their own code. They also take 5x longer to deliver the NEXT release, where as people like Kyle and myself are able to maintain sustainable, reliable delivery of features throughout the life of the project. We can do this NOT because we spend EXTRA time designing, but because we spend LESS time writing brute-force/stupid code. The design skills and principles prevent us from WASTING time on stuff that doesn’t need to be done — from WASTING time writing code that is setting us up for pain, friction, and lost time later down the road.

    Good design rescues time from the project and can actually speed delivery or at least allow for better scaling of project participants and ultimately more features in the long run.

    It’s OK to not know good design and be trying (most of us are always trying to get better), it’s the ones who don’t know good design and then ignorantly rail against people trying to talk about good design and try to demean them with petty insults and ignorant blog posts about why Dependency Injection is stupid, etc.

  • http://chadmyers.lostechies.com Chad Myers

    @Colin:

    “shoddy design on time”

    Oh man, I don’t know about you, but the vast majority of shops I’ve been in had entire teams using this philosophy. The company, for some reason, was happy to keep paying them to write and rewrite half-assed solutions over and over again and never seemed to get that they could have 2x the functionality in 1/2 the time for 1/2 the cost and not have to re-write every 3 months.

  • http://colinjack.blogspot.com Colin Jack

    @Kyle
    “Thanks for pointing out my crappy wording, Colin (seriously). Again, sorry for the lash out.”

    Na I shouldn’t have gotten involved and I definitely hope you manage to turn things around at your place.

    @chad
    “People like Kyle and myself wouldn’t be employed if we didn’t deliver projects on time and exceed customer expectations”

    Definitely was not meaning to infer you don’t. My views match yours on 95%+ of this stuff and I definitely don’t consider it ivory tower nonsense.

    However I can also see that you *sometimes* need to sacrifice some of that, mind you very rarely and not for long running projects and it isn’t a lot of fun. I’m with Greg on that aspect but I still start out every project assuming that it will last and should be designed well.

    “It’s OK to not know good design and be trying (most of us are always trying to get better), it’s the ones who don’t know good design and then ignorantly rail against people trying to talk about good design and try to demean them with petty insults and ignorant blog posts about why Dependency Injection is stupid, etc.”

    Agreed, I was worried I was being put into the second category which is why I responded! :)

    “Oh man, I don’t know about you, but the vast majority of shops I’ve been in had entire teams using this philosophy. The company, for some reason, was happy to keep paying them to write and rewrite half-assed solutions over and over again and never seemed to get that they could have 2x the functionality in 1/2 the time for 1/2 the cost and not have to re-write every 3 months.”

    Same, and I whole heartedly agree its a massive waste of time and effort (and you lose your staff if you work that way, but thats another story). Only solution is to buy big heavy books like DDD/PoEAA/Agile Principles and lob them at anyone that things quality is unimportant.

  • Kyle

    Colin said, “Same, and I whole heartedly agree its a massive waste of time and effort (and you lose your staff if you work that way, but thats another story). Only solution is to buy big heavy books like DDD/PoEAA/Agile Principles and lob them at anyone that things quality is unimportant.”

    I found your statement about losing your staff to be interesting. It’s interesting because that’s what seems to be happening at my current place of work. The new head-ish boss who took over is A) a control freak, and B) completely ignorant of any and all design principles (if anything, he follows most of the anti-patterns you’d see around the net) – and tons of people know it and are prepping to leave, myself included. What were your thoughts when you wrote that statement? Just curious. My boss has claimed in the past that, “Some people are fine just implementing low-level solutions all the time – they don’t want to learn more about software design and principles.” And I think it’s ultimately that philosophy that will be the reason that most of us are quitting.

  • http://colinjack.blogspot.com Colin Jack

    @Kyle
    Yeah I’ve been in exactly the same situation more than once and the truth is I did my best to change things until I realized it was pointless then I left.

    Truth is I learned nothing from the experience. Maybe, just maybe, you can turn things around in such a situation if you can get the support of enough of the team and you can convince a senior manager that the situation is dire but is it worth it when there are places out there with good management?

    It is amazing how one or two bad developers/managers can totally destroy a team, and once the first few good developers leave it becomes a flood.

  • http://theruntime.com/blogs/jacob/Default.aspx Jacob

    @Chad: woah. That was a lot of heat for daring to offer a counter-opinion. Or is that in defense of Kyle? I thought that Kyle’s defense of himself was perfectly well done. It was both temperate and reasoned. I’m sorry I was as harsh to him as I was because it is obvious from his explanation that he’s reacting to a bad situation (and one that most of us have been in and recognize as the suck that it is). We all have those times when we assert more aggressively than we mean to.

    That doesn’t seem to be the case with you, though, Chad. If anything, you seem to have meant your points more aggressively than you stated originally. It seems that any difference of opinion is, to you, tatamount to blasphemy and unworthy of reasoned or detailed response. You’ve only offered insults and abuse to those who make points you disagree with. So far, your only counters (besides ad hominem attacks) have been tautologies, statements of absolutes and appeals to authority. Those who already agree with you may find that adequate. I’m sorry, but I do not.

  • Kyle

    Interesting. I just found this:
    http://c2.com/cgi/wiki?FirstLawOfProgramming

    From a blog post at:
    http://bytescrolls.blogspot.com/2008/08/first-law-for-unruly-software.html

    I have to say the obvious thing: Duh. Not that pointing it out was a bad thing! But if you reduce quality, in my experience, it has always taken longer to develop the product (especially with highly technical apps where nastier bugs can crop up more often, which is what I do). Often, the domain is difficult enough – you shouldn’t make it harder on yourself (I assume).

  • http://bytescrolls.blogspot.com Haris

    @Kyle

    Got an interesting part about those agile practices

    http://www.infoq.com/presentations/Natural-Laws
    reply

  • http://colinjack.blogspot.com Colin Jack

    @Kyle
    Good link and in my experience its all true. Been on projects in the dim and distant past where quality wasn’t important and they all failed or went way off budget and had high staff turnover.

    Problem is that, as they say on the wiki, if someone doesn’t already know they you’ll have a hard job convincing them of it.

  • Philip Schwarz

    Chad,

    Nice post.

    Like you I value greatly uncle Bob’s approach of applying OCP, DIP, LSP, SRP and ISP to remove design smells, but we mustn’t forget that Bob advocates a ‘take the first bullet’ strategy: the principles are only to be used to remove existing smells, not to future-proof your application based on speculation about the changes it is likely to face, because doing that leads to the design smell of Needless Complexity.

    Martin fowler also has some great thoughts on when it makes sense not to bother with a good design…see his design stamina hypothesis (if you haven’t already).

  • Philip Schwarz

    The URL I included in my post got mangled…here it is again: http://martinfowler.com/bliki/DesignStaminaHypothesis.html

  • http://yuwanitwhen.com Bill Miller

    Great post. It’s nice to know some programmers still care about good design and know it when they see it. I thought it was a lost art. A good design with all the characteristics that you identify is the essence of agility.

  • http://dev.net.ua/blogs/mikechaliy/ Mike Chaliy

    “Just to check, are you saying this is what you think myself and others were talking about on Twitter?”

    @Colin Jack or anyone who know, could you please point me on that talk on the twitter?