Moving Forward in the Construction Phase

We saw what PSP Tools was capable of at the end of the Elaboration phase. It is helpful to review some of the major limitations. You could not:

• Create a database from within the tool

• See the details of time and defects

• Count lines of code from any subtool in the product

• Create any type of report

There were also several tasks for which there was UI support only, but no implementation had been written. For example, you could type into several fields and the system appeared to record the changes. Or, when you typed a new time into the time summary data for a task, the data persisted if you viewed a different task and returned to the original one (see Figure 8.6). However, the information was not stored in the database.

Figure 8.6. Time summary tab for a task

The reason that the data persisted was that the displayed object had not yet been released for garbage collection. If you quit and restarted the application, the changes were lost.

At this point in the project, try to avoid features that "apparently work." Your team can spend a lot of time understanding them. On our project, the testers couldn't tell whether certain features were mocked up (and weren't supposed to work yet) or whether they were supposed to work but didn't because of bugs. Sometimes we ended up filing a defect against a feature that wasn't supposed to work in the first place. The developers then had to spend time figuring out whether someone had sneaked in a surprise feature that contained bugs or whether they were dealing with a feature that hadn't actually been implemented. It's worth spending time either to make sure that a feature works completely or that you add code to make it obvious that the feature isn't yet completely implemented.

Another example of this phenomenon occurred with the Elaboration phase release. We all implicitly understood that the database was not getting updated when we modified the fields. It was less obvious that the database was not being updated at all. If you added a new task, it showed up in the tree on the left and you could click on it to see the data. But when you exited the program and returned, the task was missing. A better solution would have been to display a message saying that changes to the database were not permanent.

Handling Database Changes

Early in the Construction phase we needed to change the database schema. We hadn't thought about database schema changes until this point ”either the frequency or the method. An early solution was to use a database utility, Cloudview, to update the database schema with standard SQL statements. This approach required someone in a system administrator role to execute a script, or worse , manually enter SQL statements. For early development changes, this would be good enough, but it wouldn't be an acceptable solution for production.

The first time we changed the database structure, we used the Cloudview solution. We could continue to use this approach until the Beta release, but then what? Looking at our Vision beyond version 1, we expected to add several features. We weren't sure what form they would take, but they would have a significant effect on the database. After we thought about this problem for less than a minute, we rejected the option of relying on human intervention to keep a database updated.

We decided to record a version identifier in the database. This identifier corresponded to the database version, not the product version. When the software detected a version mismatch, it would ask the user if the database should be updated, and do so automatically. If the user declined ”perhaps to back up the database first ”the software wouldn't update the database, but also wouldn't let the user access the database. See Chapter 9 for details about our solution.

One nice feature of the solution was that users were required to update only once, even if their database was more than one delta from the current version. The solution we implemented handled the incremental updates.

If you are experienced with database applications, you have probably already internalized the need to provide for database migration. If you aren't so experienced , we suggest this lesson learned: Consider how your database will be updated, because it is a certainty that it will need updating .

Working Toward a Usable Product

Our first accomplishment in the Construction phase was to produce a version of PSP Tools that we ourselves could use. Gary had been using PSP for years , but had been manually tracking his work. He was eager for the tool to automate many of the mundane tasks that he had been performing manually. Specifically, he wanted the ability to enter the data and for the tool to perform most of the calculations. He also needed the ability to modify entries when he mistyped them. He wanted to see all the data in the database easily. Reporting was not as high on his priority list, and as it turned out, neither was it as high on Russell's.

Chris and Gary worked at a steady pace to implement the needed functionality. Every few weeks, they produced a build that was ready for testing. When the build was released, anyone could, and everyone was expected to, test it, and report any defects found. Russell or Gary often added requests for enhancement; after considering priority and effort, these became new requirements. Then Russell and Gary would reallocate work based on the priorities. We did all this without a formal planning cycle.

It didn't take long to create a usable product, what some projects call the Alpha release. At this point, Gary could use PSP Tools as his primary mechanism for recording PSP statistics. In the next few sections, we briefly describe the iterations added to each drop leading up to the Alpha release.

First Construction Phase Iteration

When we exited the Elaboration phase, there was only one working menu item, as shown in Figure 8.5. We placed our limited set of commands there. It was time to expand our repertoire . We concentrated on implementing a Project menu containing all the commands you could invoke on an open project. Figure 8.7 shows this menu.

Figure 8.7. First Construction phase iteration ”addition of the Project menu

The tabbed panes in the right panel take up more real estate than in the previous release. This was closer to the look we eventually wanted. At this point, the size of the panes was not consistent from one view to another. We found that working in raw Java without an IDE made it challenging to lay out user interfaces.

Introducing a Delighter

We made a change at this point that was not part of our requirements. One day Chris got frustrated when he was testing his code changes. Every time he wanted to open a database, he had to navigate to the directory containing that database. He usually worked on the same database for his testing, but the program always started in the user's home directory. We had previously discussed how to track user preferences and Chris was looking into the XML interfaces available in Java. Now he had the opportunity to implement something based on his research, starting with a simple example. His design statement was: "Whenever the user opens a database, record the database information in a user preferences file. Next time the program runs, put an entry into the File menu so you can directly open that database." The solution is shown in Figure 8.8.

Figure 8.8. Open previous database menu item

Some people call this type of feature a delighter . Delighters cost little to implement and bring pleasure to the user, or make the user's job much easier. They aren't a substitute for required functionality, but they add to the user experience once the required functionality is in place.

John Whiteside, author of The Phoenix Agenda , related this story to a team he was coaching. He had purchased an expensive new car. The first time he had to change a tire, he went to the trunk, and in the tool case that held the jack and wrench was a very inexpensive pair of cotton gloves. The manufacturer had included the gloves so you wouldn't get your hands dirty. It cost very little for the company to add the gloves to the car's tools, but the value to the customer was significant. It showed that the company cared about the customer's needs.

This brings up another lesson learned (or one that we knew already and reapplied): Throughout your development process, look for the opportunity to add delighters . If you can identify something that costs almost nothing to add, and it will delight a user, consider adding it to the product. The danger, of course, is that you can convince yourself that your favorite feature is a delighter, when the reality is that you may be biased . Make sure the whole team agrees that the feature is truly a delighter if the cost of adding it, and perhaps having to remove it, isn't close to zero.

We added one more feature to this iteration ”the ability to enter and view defect and time entry details. This gave us the basic functionality we needed to use PSP Tools to record our statistics. Figure 8.9 shows what we implemented for time entries.

Figure 8.9. Time entry input dialog

Second Construction Phase Iteration

The first Construction phase iteration was a warm-up for us ”it helped us get into the rhythm of delivering frequent releases. In just a couple of weeks, we released the second Construction phase iteration, adding significant new features:

• A simple Help menu item that displayed a build identification we could use when reporting defects

• A more robust and complete Project > New User interface

• Database updates (this was the first time we could see the effects of adding records and data to the database)

The Help > About PSP Tools dialog box is illustrated in Figure 8.10. Every program has a Help menu that usually offers more than the simple About box that we produced. In fact, the PSP Tools Vision shows our original intention to provide online help only and to omit printed manuals. The menu item we implemented in this iteration provided the placeholder for our online help system, and also gave us a quick way to find out what build we were working with. So at least defect reporting and tracking were easier from this point.

Figure 8.10. Simple About dialog added in the second Construction phase iteration

In the first Construction phase iteration, we implemented the ability to add a new user to the project database. However, the original implementation was simple and didn't allow the user to fill in all the data. The New User dialog box in that iteration just asked for the login name and password, if any. All other user data was set to default values, usually blank. Figure 8.11 shows the new dialog box from the second Construction phase iteration. Now a PSP Tools user could create a database for use by more than one engineer. ^[8]

^[8] Any user could add another user, without needing special privileges. We originally planned to assign privileges to certain users, but never implemented that in the first release.

Figure 8.11. New user data entry dialog box

During this iteration, we became more comfortable with the Java layout managers, as reflected by the appearance of the dialog box in Figure 8.11. The field widths are uniform and they line up neatly along the vertical axis.

We knew we needed to make our dialog boxes more consistent and attractive, but early in the project beautifying our product was not a high priority. However, some of our stakeholders started to complain about the "ugly" appearance of PSP Tools. While this issue is not critical to product usability, it is still important. We recommend that you plan to spend some time working on the user interface aesthetics as early as possible. It is tempting, when time pressures intervene, to convince yourself that it really isn't that important. But it is important ”it affects the user's experience of your product. First impressions do count, especially in software.

Third Construction Phase Iteration

We released the third Construction phase iteration only a week later. Until this release, you created a database by running the createdb .sql script in Cloudview. In this release, we implemented a menu item that allows you to create a database from within PSP Tools, making testing easier.

We also added the ability to right-click on the items in the tree, causing a shortcut menu to appear. The shortcut menu offers the same choices as those that are on the Project menu. The entries in the Project and shortcut menus are enabled based on what is selected in the tree. The shortcut menu shown in Figure 8.12 is an identical copy of the choices available on the Project menu at the time. ^[9]

^[9] During the Construction phase we were continually adding new capabilities to the different menus. The set of features shown here is different than the Project menu features shown in Figure 8.7, because this figure is from a later iteration.

Figure 8.12. Context-based pop-up menu

Once we wrote the code for the regular menus, it was easy to write the code to enable the shortcut menus. There was a problem with the initial implementation of the shortcut menus. They behaved in what felt like a buggy manner, but we didn't know exactly what the correct behavior was. We researched how other products behave and then followed what had become our usual approach ”we asked Russell what he thought. We wanted to adhere to standard look and feel practices, but when there was a choice, the best place to seek guidance was with our customer.