The Smells Of Bad Design

The Smells Of Bad Design

• 1.
  The Smells ofBad Design Is our App rotting?
• 2.
  The Smells RigidityFragility Immobility Viscosity Needless Complexity Needless Repetition Opacity http://davidhayden.com/blog/dave/archive/2005/08/09/2421.aspx Robert C. Martin Agile Patterns Practices and Principles in C# 2007
• 3.
  Rigidity System isdifficult to change. What is more difficult than should be expected? Unanticipated repercussions to simple changes “It was more complicated than I thought!” Was it really harder than apparent or were we just unfamiliar with the technology? “We can’t do that because of how it’s written”
• 4.
  Fragility Breaks downwhen a single change is made. Often a break where there is little or no visible relation to the change. What defines a ‘visible relation?’ Areas that developers are afraid of or constantly say are dangerous. “ The transfers page needs help” “ I’m not touching the Login page again” Often times fixing the problems causes more problems. We could Test “harder” but what can we do proactively?
• 5.
  Immobility Parts couldbe useful to other systems but are unable to be reused. “Well, our system has a component that does that, but it’s tightly tied to the SDK” Reusable business logic getting repeated. What business rules should we be responsible for? If it’s reusable, it should be moved to web services for the enterprise.
• 6.
  Viscosity Two formsSoftware Environment
• 7.
  Software Viscosity Wecould change this piece of code by making the ‘good design’ choice or the ‘hack’ The hack is easier. What is a hack? What is clean code?
• 8.
  Environment Viscosity Compilestake too long so the developers makes a change to ensure the least amount of compile time. (change 1 class instead of all the classes needed) The build is so slow, it’s simpler to throw this into the UI than modify the Middle Tier What about our build annoys you as a developer? Tester? Manager?
• 9.
  Needless Complexity Unusedmethods, attributes, variables, unreachable areas of code. Preparing for a future that may never come. Are you allowed to introduce scope creep any more than the business? JIT Time Weight of dead code (size, maintenance, memory, documentation) How are you USUALLY able to tell what code is doing?
• 10.
  Needless Repetition Fravlethe Arvadent example. Copy/Paste coding Hard to maintain the infinite repeats of similar code. Find 1 bug and have to search the code base for every implementation.
• 11.
  Opacity Difficulty tounderstand One person’s simple is another person’s difficult. What is simple to you? Intimacy with the code wears off, do you know what it does? Code commenting, Peer review, Test Driven Design, Coding Standards… what else could help?