Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Smells Of Bad Design


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

The Smells Of Bad Design

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