A development story

At the end of 1997, I was asked by BIC Sardinia to develop a system aimed at supporting business people who search for eligible government grants. The system consists of:

1. a Web service thathelps users who seek a government grant, and
2. a local service used by domain experts for updating the database containing information about available grants.

The system was divided in two modules: the Web interface (HTML pages and Web server) and the grants database module (GDM). A local software firm implemented the former, while the latter was developed by me (acting as coach), two students, a software professional and a developer from the above firm dealing with interfacing issues.

The developers, located at different sites, worked part-time.
The system works in the following way:

1. The user connects to the system Web site; she is prompted to provide information about her business plan. I will not discuss this part as it was implemented by another team. We experienced many delays caused by the development of this module, that was made using a commercial engine and traditional approaches.
2. The Web server queries the GDM about available grants; the module selects the information that matches the user's profile.
3. Dynamic Web pages are automatically generated by GDM and made available to the user.
4. The database is continuously updated by BIC employees; it is flexible enough to match new laws unknown at the time it was designed.

We developed the system in Smalltalk Express. The first release delivered to BIC required 15 man-months over a period of six months. Since that the project was continued, improving the GDM and adding the communications with the Internet. At the beginning of 1999 the system was operational and it can be seen online (it operates in Italian). The main difficulty in implementing the system was the need to manage loose information such as those present in laws and legal documents. This was accomplished building a meta-level able to describe present laws and to be tuned to describe future laws.

The process

Since I attended OOPSLA 97 and I was at the presentation of Chrysler C3 project, I knew about XP. So, I tried to apply many of the practices read in XP Wiki and in the C3 project site (later Xprogramming.com). I believe that this was one of the first attempts to follow many of XP practices, that at that time were less refined than today. Surely this was the first attempt in Italy.

We deployed a lightweight process for system development, addressing the following issues: manage a loose, part-time team; use XP; develop system documentation in UML (to this purpose, we used a reverse-engineering tool, named UMLTalk, developed in Visual Smalltalk at Cagliari University, able to import/export an OO model from/to Petal files and Smalltalk chunk files). The process has been presented in a paper at XP2000.
In short, the development worked in this way:

1. Requirements elicitation was done collecting user "stories" (in this case about 30 at the start of the project), considered relevant for illustrating the system’s behavior.
2. A conceptual analysis was performed with CRC cards, later stored in UML class diagrams. We identified 22 domain classes, together with subsystems (i.e. packages), dependencies among classes, inheritance relationships, and responsibilities.
3. Domain classes were then refined, typically turning collaborations into associations and responsibilities into attributes and operations. This resulted in UML complete class diagrams.
4. The UML diagrams were imported to UMLTalk and Smalltalk code (class definition and methods names and comments) was generated.
5. Then, the development tasks were given to team members, located at different sites, on the basis of user stories.
6. All developers worked with the same environment and had at home a system identical to those of other developers. Unit tests were developed together with code.
7. Developers were in contact through e-mail, checked at least twice a day.
8. The coach acted as reference point, collecting developers' deliverables, integrating them and sending back the integrated system to everybody. This happened every week.
9. If he could not solve an error, he did not integrate the wrong deliverable and returned it to the responsible developer, together with the system with other deliverables integrated, signaling the problem and giving the developer the task to solve it.
10. The coach attended frequent meetings (once in 1-2 weeks) with the user, often in presence of other developers who could attend.
11. The user was available to be contacted via e-mail by any developer, and agreed to answer questions as soon as possible.
12. Smalltalk code was imported every month to UMLTalk and from here to Rational Rose to keep the needed UML documentation aligned with the actual system. Also, textual documentation in RTF format was generated by UMLTalk.
13. Collective code ownership and refactoring were adopted.
14. Pair programming, user on site, planning game and functional tests were not used.

Setting up the process

I ideated the process and proposed it to the customer and to other team members. The customer trusted our team and was very collaborative. He agreed with the proposed implementation technology and process. BIC users answered quickly to our questions, also because they were employees in charge of setting up the system. They had to wait for our application to be able to actually input the data (they made preliminary work using MS Word and Excel, but they were anxiously waiting for the software).

The other team members accepted the process and were glad to participate in a project they felt "high tech". At the beginning, they did not contribute to the process definition. Two of them were my students and one was and experienced programmer, very reactive. The fifth member's main responsibility was to manage the interface with the Web server, being less involved in the project than other members.

In the reported experience, my authority over the team (and over the customer) was undisputed. For this reason, at the beginning everybody accepted to adopt the process. As time proceeded, the project delivered to the customer, and team morale was always high, so we did not feel the need to change or improve it. Moreover, the parallel development with traditional techniques of the Web server subsystem by another team experienced many difficulties and delays; so we were the "good team", and we had also plenty of time to refactor while waiting for the other subsystem. In this project we were very lucky, and almost all went straight.

Major challenges encountered:

• At the beginning of the project, the users came with a document already written by them with the complete data structure of a typical grant to be stored in the system. At first we tried to split and convert the document into simpler user stories, but the users did not agree, so we considered it as a single user story. Of course, the data structure evolved during the project; it was not implemented straightly, but creating a data meta-level to enchance the flexibility of the system.
• The requirement of using UML documentation was agreed between the customer and us at the beginning. During the project, the customer did not insist on it, since his goal was only to have a good working system. However, we were glad to make use of the reverse-engineering tool, as it allowed to produce a big documentation of the system almost automatically.
  I found that customers are always happy to receive big docs when the system is officially shipped. We are also happy to be able to produce them very quickly.
• The distributed software development worked well because:
  
  • Team members were first class developers
  • The system was naturally partitioned in relatively independent subparts
  • Smalltalk IDE and debugger are great and suited to this kind of development
  • The coach (I) knew very well the system and had the time to do the job
  I had to send back the deliverables to team member only twice during the project.
• Unit tests often did not covered all the features of the tested class, but only the main features. Moreover we did not implement functional tests.
• The developers tended to specialize in specific parts of the system, refactoring that part and experimenting only marginally collective code ownership.

In conclusion, the approach worked well, enabling to deliver on time a working system of good quality. However, the system size was quite small (65 Smalltalk classes, including GUI classes, in its last version), and some environmental conditions were exceptionally favourable, like the trust in the coach, a "bad" team working in parallel, the level of developers, the coach's knowledge of the system, the flexibility and suitability of Smalltalk IDE.
So, I cannot draw conclusions about the possible scaling of the approach -- more experience is needed to validate it. I can only say that the approach did not show clear faults or problems.