The Development Approach
The Development Approach
You'll begin to utilize some development practices typified by eXtreme Programming (XP). Don't let the name fool you. XP is a collection of agile development methodologies, and the following list of practices were best characterized by Kent Beck in Extreme Programming Explained (Addison-Wesley, 2000):
-
Planning Determine the scope of the project by combining business priorities and technical estimates, continually updated.
-
Small releases Get the system used by the people to be using it and release new versions on a very short schedule.
-
Simple Design Keep the design as simple as possible at all times. Complexity is removed continuously.
-
Testing Developers continually write unit tests to ensure that the system runs flawlessly all the time. Customers write tests to demonstrate that features work as required.
-
Refactoring Restructure the code without modifying the behavior to keep it easy to read, to remove duplication, or to simplify.
-
On-site customer The WW-SFAT Manager is half your team and is available at all times to answer business-related questions.
These practices allow you to manage the complexity and scope of both the project and the software that you are developing. A typical system flows similarly to this curve (Figure 18-2).
Figure 18-2
By managing complexity from many different angles, we make the curve drastically different (Figure 18-3).
Figure 18-3
Creating features as you need them is a great way to manage the complexity of your system. The cost of adding features later is not significantly higher than it is now (whenever "now" would be in the process), which means that you aren't forced to guess about what you think you'll require in the future and avoid building features that are not used.
Think of it like this: Using the traditional approach to complexity, if the cost to you (in time) is $5.00 to add a feature now, but later that same feature would cost you $100.00, it would be safer to add it now.
But if you manage to set it up such that the cost to add the same feature now is $5.00 and the cost to add it later is $6.00, then you gain little to add it now. Omit it for now; your system stays simpler, and you end up only with features that are used from the outset.
What Does this Mean to Me?
Consider the traditional waterfall approach first documented by Dr. Winston W. Royce ("Managing the Development of Large Software Systems: Concepts and Techniques," Proceedings of IEEE WESCON, August 1970.) Figure 18-4 represents this concept, which calls for:
-
Two weeks of gathering requirements
-
Two weeks of analyzing and debating them
-
Two weeks of designing the system
-
Eight weeks of coding it
-
Four weeks of Quality Assurance and other testing
Figure 18-4
Although very regimented in its ways, the waterfall model tends to be implemented as a shotgun approach and has a couple of weaknesses:
-
It lacks flexibility and assumes that design will be done correctly the first time. With a span of weeks between phases, little or no time is available for a feedback loop, and, of course, hindsight is 20-20.
-
It is hard to predict needed features because requirements are more than likely to change.
This certainly sounds almost like a setup for failure, which is why you're going to follow Kent Beck's principles (listed previously) in order to create a small, flexible system that is thoroughly tested as you write the code. You will work closely with your WW-SFAT Manager and get all required questions answered. Your WW-SFAT Manager has a wide breadth of Widget World business experience and will use the system on a daily basis.
It also means that you'll fix problems that you see and remove functionality that is no longer required. You'll stick to the "once and only once rule," which means that you'll consolidate duplicate logic and you'll be ruthless about it. Refactoring mercilessly keeps your entire system lean and powerful.
Finally, you'll have your unit tests. By testing every piece of functionality that you create, you'll constantly have a fully tested system. A fully tested system is very powerful because it makes you keenly aware of breakages and symptoms that are caused by secondary or tertiary bugs. A fully tested system lets you know instantly when something went wrong.
Having the safety net of a well-written test suite allows you to indulge in modifying features drastically. The test suite does not shackle you unnecessarily, but rather allows you to be a bolder developer by letting you take your system in different directions as and when business needs change.
This is really just a 10-minute introduction to XP, which is one of the more agile development methodologies. It's okay if you don't quite buy everything that you've just read, because you'll explore in the next few chapters how this methodology truly pays off. Soon, you'll come to realize that by using the practices described here, you'll not only be shipping software that is small, fast, flexible but adapting a process which allows your client to be actively involved in the development process.
The Technology
Although you've been warned about not building too much up front, these are some of the technological features that you'll be touching upon:
-
Where appropriate, the design snapshots (class and sequence diagrams) will be shown in UML; a quick cheat-sheet is available.
-
Design patterns, how to effectively use them and how to spot them in your code.
-
Collections and iterators, where they make sense and where they don't.
-
Dispatchers, just to get a taste of event-driven programming.
-
SOAP, for one of the data-feeds.
