Practice3.Simple Design

Practice 3. Simple Design

Simple design means you should only design and code what you know you need while always striving for simplicity. In the pure definition of simple design (such as in Extreme Programming) the goal would be to only design what you need immediately. The problem with this purist approach is that it can lead to oscillation, where a body of code is continually refactored to meet the current requirements because there was no design or planning ahead. If you know that something is going to be required, then you should design it and build it even if this means the user may only see a limited immediate benefit. But you need to keep the design as simple as possible. Add the interfaces later that you don't immediately need, for example. Likewise, if a problem is understood well enough to know that its solution can be found in a design pattern, then the pattern should be used because patterns work and are well understood. But patterns aren't perfect (see the Design Pattern practice below), and again you need to always think about simplicity first.

Simple Design and a Hotkey Manager

Simple design, when taken in its pure form (design only what you need immediately), can be a dangerous practice. I observed a project where a number of features required a hotkey manager that mapped a user-defined keyboard hotkey sequence into an application command. Unfortunately, the first two developers who added commands that had hotkeys associated with them did it by hardcoding the hotkeys. Their code worked, but a third developer had to add a new command and realized that the first two simple hotkey implementations conflicted with the changes they needed to make. The result was a major and messy unplanned refactoring exercise that set the project back.

Everyone on this team recognized they needed a hotkey manager. Some simple upfront design work could have made the total amount of work much less. Admittedly, the addition of the first hotkey-based command would have been harder because the architecture would have to have been built before the feature. But this work could have been scheduled as an explicit feature (it's good to have visibility in the team that architecture work is being done), and it would have made the addition of all subsequent commands trivial.

Scanning ahead is required. Think about evolving a simple but solid hotkey manager over time, not trying to design the ultimate hotkey manager immediately. This gives you the most amount of flexibility with minimal effort.

Tip: Making architecture work visible to users

In agile development, it is sometimes hard to get architecture work recognized. The cards are user-centric features, as they should be, and users can too easily dismiss architecture work if it doesn't have a recognized benefit.

One effective way I've seen to deal with this problem is to attach architecture cards to user feature cards. The architecture cards not only document what architecture and design work needs to be put in place in order to enable the user feature, but they also document the benefits (from a user's perspective) of the work.

In the hotkey case above, a benefit of having a well-designed hotkey manager would be that it makes the addition of subsequent commands trivial. If the users can't see or understand a benefit to architecture work, then perhaps the work isn't necessary after all . . .

Some readers may be uncomfortable with the gray area surrounding being certain that supporting architecture and future extensibility are required. I think it's important to accept that you're going to get it wrong sometimes and over- or underdesign in some instances. That's software development. Fix the problem as soon as you can, learn from the experience, and move on. Teamwork, knowledge, experience, and collaboration are vital to make the right decision. The more people make design decisions with others and use each other as sounding boards for ideas, and the more people learn from each other, and the greater the collective experience and knowledge in the team, the greater the chance that the correct decisions are going to be reached.

Sustainable Software Development. An Agile Perspective
Sustainable Software Development: An Agile Perspective
ISBN: 0321286081
EAN: 2147483647
Year: 2005
Pages: 125
Authors: Kevin Tate © 2008-2017.
If you may any questions please contact us: