Meet the Team


I spent the weekend contacting some of the folks from work. I could think of many good candidates, but I knew that most of us were already over-committed with work projects and lives outside of work. Luckily I thought of three people who were willing to work on this project. As a group , we share many interests, and we have different but complementary skills. The combination seemed ideal.

Before continuing the story, let us introduce ourselves .

Gary

I'm the originator of the project. I'm the oldest, in terms of age, years in the computer industry, and years spent in school trying to get a graduate degree. I'm also the curmudgeon of the group. In fact, my title at work is Curmudgeon, and that's the job title on my business card. According to the Merriam-Webster online dictionary, a curmudgeon is a "crusty, ill-tempered, usually old man." While I try not to be too ill-tempered, people tell me that I am crusty, and there is nothing I can do about my age.

I've worked in the computer industry for more than thirty years. I started in business systems and then went into more technical areas such as compiler and tool development. Along the way I was fortunate enough to learn a lot about software engineering at places such as the Wang Institute of Graduate Studies, one of the first schools in the country to have a program focusing specifically on software engineering.

I get great satisfaction when a program or system that I work on comes to life and is successful in the marketplace . I have always enjoyed small projects where we seem to get a lot of work done without a lot of overhead. My least enjoyable jobs have been where the project team was large or the organization had a burdensome amount of red tape, usually called process . When I look at the enjoyable times, I remember following a process, but one that was a help and not a hindrance. My goal for this project is to deliver high-quality software to Russell and his group. At the same time, I want to capture a real example of a small project where process and tools helped deliver the software and where we had fun working on the project.

Several years ago, I learned of Watts Humphrey's Personal Software Process. I tried it and found that it made me a better engineer, even though I only reached PSP level 1. As a result of using PSP, I was better able to predict my performance and to reduce the number of errors I produced. I readily admit that the PSP bookkeeping was difficult and time-consuming . I always wanted to build tools to make the record keeping and analysis easier.

PSP is a help to me as an individual engineer, but there are very few projects I work on by myself. There is more to building software than programming and measuring myself . When I first saw RUP, I thought it was intimidating. It covers the full set of disciplines required to produce a software product, and it consists of about two thousand Web pages. No matter how you count, that is a lot of information to absorb and put into practice.

As I got to know RUP better I realized that it could work well for small projects. In recent years, I have tried to explain to small teams how they can effectively use RUP. There is a difference, though, in telling someone how to do something and showing them. This was my opportunity to prove it.

Liz

I've been interested in software development practices for most of my twenty years in the computer industry. During my early days as a programmer, I went to school part-time to get a bachelor's degree in computer science. The combination of studying theory at night and applying it by day was powerful.

As a programmer, and later when I switched careers and became a technical writer, I've focused on programmer development environments. My emphasis has always been on making my users successful at their task. In fact, I think of my job as "helping my customers go home at night." I realize that the tools I work on are not interesting in themselves ; they're valuable only if they help users do their job more effectively. As a result, I've studied user interface design and have more recently become interested in an emerging field, information architecture, which focuses on the design and presentation of large amounts of information.

Through these two decades of working in the computer industry, though, I've often wondered why we seem to make so little progress toward writing accurate, reliable software in a predictable way. We have new tools, technology, and processes, and yet most software I use seems no better than it did twenty years ago.

So, I'm especially interested in this project. Like Gary, I love the excitement of working on a small team. I have a tendency to try to bypass lots of process if I think I can get away with it. But I like the security offered by a "light-weight" process, especially if it makes sense to me. I'm hoping that the discipline we impose on ourselves during this project results in a predictable schedule, and a usable and reliable software product.

One more note: Although I have been a software engineer in the past, I have not programmed for a long time, and I don't expect to do so on this project. I do, however, plan to help design the tools environment and the user's experience, test the software, and design and write the software documentation.

Chris

When Gary told me about this project, I was immediately interested. I had never heard of PSP, but our development group codes many small projects and we needed to use RUP better. I saw this as a great chance to use PSP and RUP and integrate them into the best coding practices promoted by Steve McConnell in his book, Code Complete: A Practical Handbook of Software Construction . I was sold when I learned that we would be developing the system in Java. Our group at work has been coding in C++ for quite a while and is migrating to Java. Participating in two small, separate Java projects at once seemed like a great immersion strategy for me. Immersion and doing is how I learn best.

I have been developing Windows user interfaces for the last eight years. I hope to bring some of that usability knowledge to the project, but my official contribution is in development and testing of the product.

With fifteen years of development experience in C and C++ in four companies, I've seen a lot of failures in software projects and a few successes. This seems to be a common thread in stories that I hear at industry conferences and in books on software development. Maybe this project will help by facilitating a few more successes.

Jas

For me, developing software is like growing a plant. The notion is that from the germ of an idea, one can, over time, and with careful management, cultivate a well- formed functionally useful entity. My experience with software as a developer and user, however, has had me on my knees, in the dirt, and to the point of eating worms.

For a number of reasons, I think Gary's idea to use RUP on a small and useful tool development project is great. I had witnessed the RUP approach of iterative and architecturally centered development salvage a million-line project from oblivion. I was duly impressed. Later I was thrilled with the opportunity to work on developing content for RUP. When Gary approached me with this book idea, I thought "Good, let's see how we apply the ideas that we had spent the previous four years debating and writing about." In another life, I went through a CMM rating process and was intrigued by Humphrey's work on PSP. So onwards to another journey!

Russell

Our customer, Russell, worked with us throughout the project, or at least we pretended that he did. Russell is imaginary, but he is based on real people we have known. In fact, there is a real Russell, who was the starting point for the imaginary Russell. Russell provided a helpful focus for us throughout the project, and Gary "consulted" with him regularly when we had implementation questions. Using an imaginary, composite character based on real user characteristics is often referred to as working with "personas." Alan Cooper popularized this technique in his book, The Inmates Are Running the Asylum .

We designed Russell as an experienced project manager. We were building software, called PSP Tools, for use by software developers who work for Russell. Russell wants to help the members of his team improve their personal performance. But Russell and his team must also deliver software. Russell is willing to be a part of our team, as a customer, so that he can ensure that what we build is, in fact, what he wants and needs. He will give us freedom to work around our other jobs, but he does expect to receive valuable software at the end of the project.

Throughout our story, we present many "Russell episodes ." We ask you to think of him as a real person. We did, and we feel the end result is better for his "participation."



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