Design Patterns Explained

23O Part V • Handling Variations with Design Patterns
This is true in
software as well: we
focus on immediate
concerns and ignore
the longer term
becomes tough to find things as the piles grow. Disaster often comes
in the long run from suboptimal decisions made in the short run.
Unfortunately, when it comes to software development, many people
have not learned these lessons yet. Many projects are only concerned
with handling immediate, pressing needs, without concern
for future maintenance. There are several reasons projects tend to
ignore long-term issues like ease of maintenance or ability to
change. Common excuses include
• "We really can't figure out how the new requirements are
going to change."
• "If we try to see how things will change, we'll stay in analysis
forever."
• "If we try to write our software so it can add new functionality,
we'll stay in design forever."
• "We don't have the time or budget to do so."
The choices seem to be
• Overanalyze or overdesign— I like to call this "paralysis by anal
ysis," or
• Just jump in, write the code without concern for long-term
issues, and then get on another project before this short
sightedness causes too many problems. I like to call this "aban
don (by) ship (date)!"
Since management is under pressure to deliver and not to main tain,
maybe these results are not surprising. However, with a moment's
reflection, it becomes apparent that there is an underlying belief
system that prevents many software developers from seeing other
alternatives— the belief that designing for change is more costly
than designing without considering change.