Why Did Development Speed Up?


Two primary factors account for the acceleration in our development. In our experience, these factors are present in all types of projects, but their effect is greatest on small projects.

Beyond the Learning Curve

The first factor is familiarity with the code base. When a project starts, there is a learning period. This is true whether you are creating new software from scratch (called greenfield development ) or whether you are adding to an existing system. Unless you have already worked with the existing code base, you need time to get used to the style, functions, and structure. To minimize learning time, organizations can establish (and adhere to) coding styles, and they can insist that developers document their code. But even in organizations where communication is consistent and useful, there is always a learning period.

By the time we started the Construction phase, we had written between three thousand and four thousand lines of code. Our architecture was stable enough that we made little structural change. We had reorganized the code ”moved classes and renamed them. This effort, called refactoring , [10] results in better code, but the tradeoff is that it can cause a short- term reduction in productivity. After the refactoring, though, both Chris and Gary could easily navigate through the PSP Tools code and find the appropriate classes and methods in the classes.

[10] There are many other types of refactoring activities. We only mention these two here. For a detailed reference on the topic, see Refactoring: Improving the Design of Existing Code , by Martin Fowler et al.

Working with the Infrastructure

The other contributing factor to our improved delivery times was that we had already developed some of the application's infrastructure, so we didn't need to stop to work on it during the Construction phase. Engineers argue about how much infrastructure code you need to write and when to write it. Do you ignore future needs for infrastructure and develop it as needed, or do you plan ahead if you are fairly sure you will need a piece of infrastructure? We chose a mix of these approaches. In some cases, we waited to develop infrastructure until we needed it. However, there were some aspects that we addressed early, even though we were not ready to take advantage of our solutions at the time we implemented them.

We developed most of the infrastructure during the Elaboration phase. During the Construction phase, we used the infrastructure code so we were able to implement specific features more quickly than during the Elaboration phase. Here are two examples of our experience.

Examples of Working with the Infrastructure

Earlier in this chapter we discussed how we created a general-purpose solution to handle database changes. Once we established the mechanism to instantiate an appropriate updater class, it was trivial to create a new class to change the database. Writing the code for the new updater class usually meant copying the code from another updater class and editing it. At the end of the project, when we had to add a field to the database, Chris and Gary implemented and tested it in less than an hour .

The second example involves the way we structured the database and the database code. As we mentioned in Chapter 6, the database contained a separate table for each data object class. One way of implementing the relationship is to have a class for each data object and a class for the database. In this case, the database is responsible for delivering the data objects to client classes that request them and updating the database when client objects send messages requesting the update. We initially implemented the database and data objects in this manner.

As the database evolved and the number of data objects increased, the database code grew until it was difficult to navigate and maintain. The eXtreme Programming community talks about the code smelling bad . The database code had a distinctly offensive odor. Our solution was to have an accessor class for each data object class, as shown in Figure 8.13.

Figure 8.13. Database accessors for each data object class

graphics/08fig13.jpg

The solution shown in Figure 8.13 provided a cleaner separation of concerns. The database class contains the necessary data and behavior to handle general database creation and maintenance operations. It also contains a field for each data object class. This field is an instance of the appropriate accessor class, and there is a getter method for each of these fields. When a client class needs a specific data object from the database, it requests the appropriate accessor from the database, and sends one or more messages to the accessor to get the actual data object.

See Chapter 9 for more technical details of this solution. The point is that by recognizing the "accessor pattern" as our software evolved, Chris and Gary were able to communicate more effectively about the work they did and the tasks that remained. This is a well-known advantage of patterns ”when you can communicate better, you will work better.

Using Our Own Software

One more factor affected our productivity in a subtler way than the two primary ones described so far. We began to see results and were able to use the system we were building ”it was good and we wanted more. When you build software that you might use yourself, a psychological lift occurs when you get to the point where you can actually use the software. Not everyone works on projects where they build such software. There may be a lift when a customer uses the software for the first time, but usually that occurs later than on projects where the programmers want to use the software.



Software Development for Small Teams. A RUP-Centric Approach
Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series)
ISBN: 0321199502
EAN: 2147483647
Year: 2003
Pages: 112

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net