Developing a large tool set like HADS can be an expensive proposition. In addition to acquiring rights to the frontend compiler technology, external consultants and Honeywell engineers were used on the project. While this was not a large number of people, it still had a cost. Some of the managers on the project seemed to resent the expenditures. At one point in the project, an Ada compiler for the AMD 29050 from an external source became available. Since there was not much of a potential market for a compiler for this target, it is likely that the target customer for this compiler was the 777 project. It may be that some at Honeywell were encouraging the compiler vendor to develop the tool set to replace HADS or as a fallback position if the HADS team should fail. One day in a hallway, Bruce, one of the managers, came up to me and said, "Since there is an off-the-shelf compiler available, they are going to kill the HADS project." Naturally this was concerning, not for the sake of my job, as there was plenty of work to be done, but because we took pride in the quality of what we had done and didn't want to see it go to waste. But Bruce was known as a guy who liked to spread a lot of rumors and who liked to make others uncomfortable, so we didn't do anything special. We just continued on with our plans. By the time the other compiler came out, the HADS team had demonstrated numerous successes. Some evaluation of the other compiler was done, but the HADS compilation system was clearly superior.

The small HADS team was very successful, producing a large, quality system without missing any of its deadlines. Of course, we had some advantages that the 777 team did not have. For example, there is a standard for what it means to be an Ada compiler, meaning that the basic requirements for the product were known from day one of the project. Another big advantage we had was that we did not need to produce the volumes of customer documentation that the 777 project's waterfall life cycle required. Except for documenting those parts of the runtime that required DO-178B certification, we produced only the internal documentation it deemed necessary for reference and only external user documentation. This made things quite a bit easier for the HADS team than for the 777 team.

But there were also some things about the team that led to its success. What were the things that turned an initially ugly team into a beautiful, successful team?

The most obvious change was that a number of people who were merely going through the motions were replaced. The result was a smaller but much more dependable group. Having people that you can't depend on is not good. With a larger team, someone who is not "pulling his weight" can be overlooked for quite a while. With a small team, it is obvious what each person is doing. We found it much better to have a small group of dependable people. The small group that did the majority of the work was also highly competent. Many of us had not worked on compilers and related tools, but we all had worked on difficult projects and had developed a great deal of competence in programming in general. Experience in developing compilers did not seem to be highly important, but experience that involved proper use of software engineering principles did seem to be important.

It was much more than dependability and competence. A collegial attitude also developed. We all shared several characteristics that led to success. Most importantly, we all knew we were good. Because we knew we were good, we didn't worry about taking credit or getting blame for individual accomplishments. Because we knew we were good, we would ask others for help when faced with a particularly nasty problem. Because we knew we were good, we did not take offense if someone else offered a possibly better solution to a problem. Because we knew we were good, we were willing to take time to help out others. Because we knew we were good, we recognized the competence of our colleagues. Because we knew we were good, we didn't feel that it was necessary to get our own way, but could be insistent when it was important. Some have said that HADS was a very egoless team, but I think that the team members all had pretty big egos; however, the big egos did not need to be fed. We all had a confidence in our abilities and the abilities of our colleagues.

We all worked very hard, and each of us worked to the maximum of his or her abilities. We worked very little overtime, but each of us came in on time and put in a hard, full day every day. Because we would ask others for help when we had problems, and because we could see our colleagues working hard each day, we always had confidence that the work was progressing.

During most of the development, each developer had the primary responsibility for developing a particular area. Some example areas were the storage manager, the exception manager, providing the linking capability to the AIMS requirements for separation of applications, register assignment, and optimizations. Since we knew the person primarily responsible for an area, it was easy to talk with the right person about an issue.

In addition to the competence and personalities of the team members, there were several practices that the team used that led to success.

Since the HADS project was being developed in-house, and the engineers on the 777 project got to know the HADS developers well, it was easy for the project engineers to approach one of us about a particular feature or optimization that he desired. This could have led to a lot of "feature creep" or conflicting requirements. We avoided this problem by insisting that all requests go through Tom, the team leader. He decided what requests should be worked on, as well as the priority of these requests. He did a good job of shielding the rest of the team from a lot of outside pressures. I'm sure that it was a difficult balancing act to protect the team and also be responsive to the 777 project.

A really helpful practice we used was to have a short (half-hour) meeting at the end of the day on Fridays. In this meeting, we assessed the progress of the past week and set the general priorities for the next week. This was pretty much a democratic process, though Tom, as team lead, had the final say. Very little general problem solving was done in these meetings, but we were allowed to give opinions about things to look into as a possible solution to a problem. Many agile teams currently use a similar concept, though they have shorter, daily meetings.

We had deadlines that were rigid on data and fairly rigid on content. The weekly meetings determined the primary focus for the next week. The "top 10" list allowed us to continually readjust focus onto the short-term problems that must be solved in order to achieve the long-term goal. The combination of longer-term deadlines, goals for the next week, and the ability to change daily through the "top 10" list provided for an agile development environment.

The development of a regression test suite, based on issues found either internally by the team or by users, provided continual feedback on the quality of the product. It also made it easy to find regressions introduced during development. When a regression was found, its seriousness could be evaluated to determine its priority and when (and where) it should be added to someone's "top 10" list.

The HADS project was quite enjoyable to work on. Much of this had to do with the beauty of the team and the success of the project. It is difficult to know whether the success—and the practices that led to success—caused the team to be beautiful, or whether the beauty of the team led to the successes. I suspect that they grew together.

Any project winds down as it either fails or produces what is needed. For the HADS team, the wind-down was gradual. Several members of the team were moved to areas of production for the 777 project where their expertise in Ada and their intimate knowledge of the tool set were beneficial. Gradually, the consultants were removed until the team was down to two people. In a final round of layoffs, I was laid off and transferred to the Honeywell Technology Center. After a few months, the one remaining team member grew tired of working by himself and he left Honeywell. Maintenance of the project was taken over by a completely different set of engineers. An irony of the project is that after all of the primary HADS developers had left the team, the HADS project was given Honeywell's Highest Technical Award.

The perspectives given in this narrative are my own. Others on the team may perceive things quite differently. Perhaps, though I doubt it, some of the primary developers would not feel that the team was beautiful. But for me, my experiences on the HADS team were one of the highlights of my career as a software engineer.