Chapter 10. The Right Tool for the Job

10. The Right Tool for the Job

This is perhaps the most important chapter of the book. This chapter goes into depth where we did not in previous chapters with the hope of lending insight into real problem solving as well as providing a useful base for a real implementation. Although we present a specific solution to a specific problem, this chapter illustrates some valuable architectural lessons and highlights mistakes often made in feature design.

Hopefully, this begs the first question. Why do I say "feature design" and not "web application design?" This has a simple answer: I have a web application. We've discussed various aspects of this web application in several of the preceding chaptersit has been designed. We are now challenged with adding something to it, hence feature design. This is the most common vector of development and as such the most common ground for mistakes.

Although some web applications have been redesigned several times from the ground up, that should never be a goal for anyone. Web applications ideally are designed once, and during that design you have the opportunity to screw everything up...once. It is fundamental that the initial design be a good one because it is the basis for all other development work. This leads into the rest of this web application's life. Every day, week, month, and year, there will be new business problems to solve that require the design and development of new features. And every time you will have opportunities to make mistakes.

This may sound intimidating, but remember that these design decisions are smaller and often easy to recover from. Feature redesign is much less intimidating than core application redesign. The trick is realizing when things are improperly designed and ensuring that they are refactored. Although these design decisions are significantly less important than the design of the core web application, bad design is still possible, and death by pin pricks is a bad way to die.