A Solo Software Project: Project Deimos

The Seminal Idea (Saturday Night)

Tonight, I met my friend Gary in our favorite watering hole. He's the software development manager in a small company. As part of an effort to improve their process efficiency and predictability, some company employees recently took the Personal Software Process training course. ^[1] But Gary has a problem: A key element of the approach is that individual developers keep track of the time they spend on each type of activity, such as requirements capture, design, testing, and administration. Each of his developers uses a different tracking strategy, and at the end of the week, it is quite a nightmare to gather and consolidate all the data. An assistant has to go around gathering all the random Post-It notes, e-mails, and voice mails that team members use to estimate how they spent their time. This is discouraging because, for a software organization, accurate measurements of the effort expended on various activities are key for monitoring productivity, identifying potential areas for process improvement, and, above all, planning future projects effectively.

^[1] Humphrey 1997.

I suggested that Gary try automating the tedious job of tracking activity effort. Developers could have little timers on their screens that they could activate, associate with an activity name , suspend when they stop for lunch or some other interruption, resume when they return, and close when the task is completed. The data would be stored somewhere safe and then retrieved and consolidated in a spreadsheet at the end of the week. "Great idea!" said Gary. "Nick, can you crank that out for me? It would save me a lot of hassle and therefore a lot of money. I'll pay you whatever you want. Well, sort of. How much do you want to develop this?" I told Gary that I needed to think about it. I had no engagement for the following week, so maybe I could crank out something in a few hours. But I quickly revised that: "Hmmmm, better make it a couple of days. Come to my office Monday around 11 A.M. , and I'll have a proposal for you."

The Proposal (Monday Morning)

I thought about the timer project a few times over the rest of the weekend , and by the time I woke up this morning, I had a "mental concept" of it, as well as one or two possible implementation ideas. But this was a serious business proposition, so I needed a serious business case. What would I build, and how many resources would I need to throw its way? Mostly, this would require my time and maybe some software acquisitions. And finally, how much would I ask Gary to pay me? So I arrived here at my office early this morning, cleaned my desk, and laid out four sheets of paper. Then, at the top of each one, I wrote one of the following headings:

• Vision

• Plan

• Risks

• Business Case

The Vision

I start with the Vision. I need to describe, for Gary and myself , what exactly we want to achieve: the fundamental need he is trying to address, what the tool will look like, and how it will be used.

My first stab at it appears in Figure 4.1.

Figure 4.1. Creating a Vision.

In the Plan, I'll sketch out a schedule for the next few days, mainly identifying major milestones ”the points at which I'll have to make a decision, either on my own or, more likely, together with Gary.

At lunch today, I'll need to reach an agreement with Gary to go ahead and to get some commitment from him at least to start paying me for the job. I'll have to have him agree on the Vision, the Plan, and my estimate. For myself, I need a private Business Case (which Gary won't see), detailing how much time I need to spend on the project. If I can accomplish all this ”getting agreement on an overall vision, a plan, and a price, and ensuring that I won't lose money ”then I'll achieve my first milestone, the Lifecycle Objective Milestone ”and bring the Inception phase to a close.

To make the pill easier for Gary to swallow, and also to cover myself in case I run into some unforeseen difficulty, I'll suggest that he commit only to paying me for producing a rough prototype, which I'll show him Tuesday evening. Only then, if he likes what he sees (and if I'm confident I can finish the project by Friday), will I ask him to commit to the total project amount.

The Plan

It's only 9:30 A.M., so I can work on the Plan. No need for heavy- artillery planning software to do a Gantt chart, but I want a rough plan that will distribute my time into major phases.

After sketching it out on a piece of paper, I decide to transfer it to my pocket agenda. My first-phase plan looks like Figure 4.2.

Figure 4.2. The Plan.

Inception. I've been working on these activities since early morning and hope to wrap them up just after lunch with Gary. If I get his commitment to pay for a demonstration prototype, then this phase will represent a day of work on the project. If he won't commit, then we'll quit there and remain good friends .

Elaboration. I think I could conclude this phase by Tuesday lunch. I'll build a rough prototype that will allow me to "elaborate" on the requirements, the solution, and the plan, and to explore some of my ideas. Then I'll ask Gary again to validate everything with me over lunch. The prototype will give us several things:

• Something more concrete to show Gary so I can get more feedback from him on the requirements (you know, "I'll Know It When I See It"). So far all he'll have had to go on is a discussion in front of a glass of pale ale and some rough plans.

• More important for me, I can validate that I really have all the bits and pieces needed to do the job on my hard drive and that I do not underestimate the amount of effort. While shaving this morning, I thought I had an idea for an architecture and the various parts I would use, but now I am less sure. Can I use this little database I used on a previous project, and will I be able to interface it with a Java applet? Where did I put the user 's guide for the API? Will that run on their OS?

• More information to create a much better plan and a more detailed schedule.

• A starting point for building the real thing, with a chance to scrap everything I did wrong.

• An opportunity to refresh my database definition skills, as well as my Java style.

I think of this crucial Tuesday lunch as the Lifecycle Architecture Milestone. At that point, both Gary and I will have the option to bail out, significantly recast the project, or go ahead with confidence.

Construction. I figure that if Gary gives me his go-ahead, helped along by a fine Beaujolais, then on Wednesday morning I'll start early to build the real thing, all neat and clean, and thoroughly test it. Then I'll ask Gary to come around 2 P.M. on Thursday and bring one of his programmers to try it out on his laptop. That will give me the afternoon to fix whatever they don't like.

I think of this Thursday session as the Initial Operational Capability Milestone because it will be the first time that actual users will try the software.

Transition. This will be the last run, and I hope it will last just a couple of hours. It'll conclude with a release ”I'll probably e-mail the software to them ”accompanied by my invoice, all by close of business Thursday.

The Risk List

I've already mentioned that I have a few doubts and worries. Rather than burying my head in the sand, I'll jot them down on that piece of paper headed Risks. I'll include anything I can think of that might make this little project fail, become delayed, or go over budget. And I'll use a pencil, because a Risk List always requires reorganization and sorting out again and again.

What's on my list appears in Figure 4.3.

Figure 4.3. Assessing Risks.

The Business Case

It's now 10:30 A.M., and I have all the information I need to build my initial Business Case, so I can begin filling in that last piece of paper. I've already estimated that the project will take four days of my time. I might need to upgrade both my Java compiler and the database software, so I'll mark those things TBD (To Be Determined). I figure that with my usual loading factor and a bit of padding for any bug fixes that might come later, it should be a reasonable deal.

If Gary is reluctant, I could even build a convincing business case from his perspective. If he were to free up a half- hour per week per developer, plus two hours of data entry and consolidation time for his administrative assistant, he would get his money's worth in less than six months. (I'm even thinking about how I could sell this little program to others through a profit-sharing scheme with Gary, but I'll focus on this some other day. Time is short.)

The Architecture

Since Gary has not shown up yet, I go a step further. On a fifth sheet of paper labeled Architecture, I do a quick pencil diagram of the major components of the timer software: Java applet, browser, database, and data extractor. It looks like Figure 4.4.

Figure 4.4. Sketch of Sample Architecture.

Then I add a couple of other components, using the UML. Since the diagram looks interesting, and since Gary is himself somewhat software-literate, I'll show it to him, too.