ReachableDesign

"must be a reachable, attainable goal."

"A goal is a dream with a deadline." - Napolean Hill

A ReachableDesign. must be reachable with respect to, "time to design", "time to implement", "time to test" and "time to deploy". After all there will always be a deadline.

A reachable design:
  • Is not overly complex.
  • Provides a solution to budget.
  • Attainable by those who will implement it and those who use it to implement other things
  • Implementable by the implementers' knowledge or requires very small learning curve.



Intent

The intent is to provide you with some considerations towards understanding the impact of a design on your deadline. It must be reachable in the sense that each step of design, equates to a step of implementation, testing, integration and deployment. Some designs can be aided with tools and sometimes tools can slow us down.



Motivation

Sometimes a good design is not reachable and you should settle for something less that good. However, design principles, such as MaintainableDesign, MinimalDesign, ExtensibleDesign and SolvingDesign all have a part to play. Sometimes good designers, with good ideas don't get anything done, because it can be a never ending cycle.



Solution

Design "in" iterations, design "for" iterations are two different things. You must make the choice between the two. When you design in iteration, it means you worry about getting the SolvingDesign within the iteration. Designing "for" iteration may mean the SolvingDesign only becomes true, after an iteration yet to come. For example, you may design a shape abstraction and work on the base classes in iteration one. However you need to draw a square and it must be a concrete implementation of the act of drawing and the class. You may then design for iteration 1 and iteration 2, but you implementation occurs across 1 and 2, and the SolvingDesign comes at the end of iteration 2.
When you design "in" iteration, you are not particularly concerned with the next iteration. You will reach SolvingDesign in iteration 1 and worry about iteration 2, when it occurs.

Both are valid, but it depends on your environment, deadline and type of design.

Therefore, consider the time it would take to reach your SolvingDesign. Consider the number of iterations you will have. Always be a little pessimistic and insert 1 more iteration before you give it to your client. That way you will have 1 iteration to amend the design, and/or implementation.

In order for you to reach the deadline, your design must not be more time-consuming to implement, than the available time. You should however start with the better design and work it down, rather than just working from the worst design as your starting point. If you can imagine you implement the solution at 50% of the original good design, you can refactor and work towards 100%. But don't start at less than 10%, because "those" never get refactored at all, ever, even with best intentions at the start.

  • Add time to create the design artefacts
  • Add time for the coding of the extensions for any extension points
  • Add time for testing of each artefact
  • Add time for refining each artefact
  • Add time for documenting each artefact
  • Add time for deploying each artefact
  • Multiply by a (100 - %withcertainty), (if you are 90% sure of the design, multiply your time by 10%)
  • Divide the time into iterations (sprints), and rework the design until it fits


Applicable Patterns

Big Ball of Mud (Big Ball of Mud)
Piecemeal Growth (Big Ball of Mud)
Throwaway Code (Big Ball of Mud)
Keep It Working (Big ball of Mud)
Sweeping It Under the Rug (Big Ball of mud)
Template method (GoF)
Factory Method (GoF)
Facade (GoF)
Sprints (SCRUM)
Pair Programming (XP)
Simplicity (XP)
Sprints (SCRUM)
Develop Overall Model (FDD)
Build Feature List (FDD)
Design By Feature (br/>

Conflicts
AgileDesign, ExtensibleDesign, MaintainableDesign
Compliments
MinimalDesign, SolvingDesign
Ammerse Principles