Software design – the structure of the code, itself – is a key element of software development work. In fact, almost all software work is actually design work. We don’t “build” software. What coders build is a plan for how to assemble software. Machines then execute that plan – either in a compiler or an interpreter – to build the actual software.
The long-term sustainability of a codebase is more-strongly related to the design of that code than it is to any other attribute. Even test coverage. If you don’t have a sustainable design, you can’t do anything… even add tests. Some even argue that the lion’s share of the benefit that developers get from practices such as Test-Driven Development is actually a result of TDD enforcing a certain minimum standard of design quality.
Software design is also one of the richest, most developed and explored aspects of software development. The gold standard for software design is the principles and patterns outlined in Design Patterns.
It can take years to become an expert in all of these concepts, principles, and techniques but, as always, there’s a way to take a first step that delivers value a lot sooner.
Recommended Program
The best way to kick-start your team’s journey to better design is with a combination of live, expert-led training and coaching. We recommend our Design Patterns 1 program, which includes a 3-day course and 2 days of follow-up coaching so the expert can help your team apply this technique to their real work.
Course
This 3-day course covers the theory which underlies design patterns thinking, the principles which drives all the patterns, and the six most important design patterns to know. Along with the practice required to make it stick.
Topics covered include:- Opening – the combinatorial problem (axes of variation run amok)
- Key Design Concepts (explanation, examples)
- The Design Patterns Principles (explanation, examples)
- Patterns transcend computing (building architecture example)
- Strategy Pattern
- State Pattern
- Template (Method) Pattern
- Abstract Factory Pattern
- Builder Pattern
- Visitor Pattern
- Conclusion
The course is interspersed with plenty of examples and exercises to help cement the ideas and practices in the learner’s mind.
Coaching
Afterward, a recommended 2-day coaching package helps learners implement what they learned in their real code using real PBIs to deliver real code the new way. This is typically done within the same Sprint as the course.
During these sessions, the coach will help lead the team through the design challenges surrounding one or more of their real work items. The time should be divided evenly between working on the whiteboard (understanding the design at a conceptual level) and working on a keyboard (actually implementing the recommended design).
An added benefit of this will be that the coach has deep refactoring skills that can be used to integrate the team’s ideal design into an existing codebase, even if that codebase generally seems to resist design changes. An ideal PBI to drive this, however, would be one that involves mostly writing new code with minimal time needed for refactoring existing code.
Benefits
Designs that adhere to the design principles in this program are easier to maintain. There is less friction involved in adding new features because you don’t need to find several different places to make a change, nor do you have to worry so much about unintended consequences.
Whereas software with numerous different concerns in it gets significantly harder to maintain with each new feature, the cost of adding new features in a “patterns-aware” design remains relatively flat.
The long-term benefits are so impactful that it is safe to say no software product survives long without addressing these forces. Not everybody calls the mental model they use “design patterns” but it is impossible to sustain a codebase without some kind of attention of the way that code is structured.
Costs
In our experience, the price tag is just a fraction of the cost of one of these transformations. We feel it is helpful to give a full view into the level of investment typically required for this kind of transformation.
There are a number of components to take into account when considering the cost of this program:- Impact on capacity
- Time to proficiency
- Risks
- Time to results
Impact on Capacity
This will significantly impact capacity during training and immediately after. The team will not be able to deliver anything during the 3-day course and is likely to deliver at 50% capacity during the two days of coaching thereafter. Therefore, when planning costs, you should consider a 4-day loss of productivity directly related to the training & coaching activities.
Time to Proficiency
You can expect your team(s) to stay in the “practicing” phase of adoption for four to six weeks.
Risks
Time to proficiency may create some additional capacity loss but, most likely, it will express in the form of mistakes.
One risk is that missed opportunities to address the forces in a problem with software design will occur but those have likely been happening all along. This can be mitigated by ensuring that engineers seek out these opportunities. Perhaps targeting a problem area of the code for an improved design or doing some deep analysis on the design of a PBI that isn’t scheduled for a few Sprints.
A bigger risk is that the team might become overzealous about applying these techniques and try to use them in places they don’t apply. This can lead to code that is needlessly overcomplicated and takes more energy to maintain.
You may need to plan some capacity for cleanup after this “honeymoon” phase ends.
Time to Results
Software design is a deep driver for many effects within a software development effort. As such, the effects of better design can take a long time to manifest.
Prerequisites
none
Enablers
none
