> Hi, This is a very interesting article that I found on the web on
> how software engineers should manage their time .
>
> Software Engineering
> --------------------
>
> *How Software Engineers should manage their time - Watts Humphrey
>
> In writing this column, I plan to discuss various topics of
> interest to software professionals and managers. In general, I
> will write about issues related to engineering productivity,
> quality and overall effectiveness. Occasionally, I will digress
> to write about a current hot item, but generally I will be
> pushing the process improvement agenda. Because my principal
> interest these days is getting organizations started using the
> Personal Software ProcessSM (PSPSM) and Team Software ProcessSM
> (TSPSM), readers should know that a not-so-hidden agenda will be
> to convince them to explore and ultimately adopt these
> technologies.
>
> *Why Does Software Work Take So Long? Watts S. Humphrey
> --------------------------------------
>
> Have you ever started what you thought was a two-or three-day job
> and have it stretch into a week or two? Before deciding you are
> just bad at estimating, look at how you spent your time. You
> will find you spend much less time on projects than you imagine.
> For example, on one project, several engineers used time logs to
> track their time in minutes. They averaged only 16 to 18 hours a
> week on project tasks. They were surprised because they all
> worked a standard 40-hour week. This information soon turned out
> to be helpful. They were on a critical project and were falling
> a behind. When they looked at the data, they found the design
> work took 50% longer than estimated.
>
> They knew they had a choice: either do the tasks faster, or put
> in more time. While there was pressure to race through the
> design, skip inspections, and rush into coding, the team
> resisted. They
>
> knew this would probably result in many errors and a lot of test
> time. To meet their schedule, they needed to average 30 task
> hours a week. They all tried valiantly to do this, but after
> Christmas, they realized that just trying harder would not work.
> They went on overtime and are now starting early in the morning,
> working late some evenings, or coming in on weekends.
>
> While they now average 30 task hours a week, they have to work
> over 50 hours a week to do it. They are also back on schedule.
> Because this team had detailed time information, they could
> recognize and address their problem in time to save the project.
> The data identified the problem and pointed them toward the
> solution. Without good data on where your time goes, your
> estimates will always be inaccurate and you won't know how to
> improve.
>
> Working harder :
> ----------------------
>
> When people say they are working harder, they actually mean they
> are working longer hours. Barring major technology changes, the
> time it takes to do most tasks is relatively stable. The real
> variable is the time you spend on the tasks. But to manage the
> time you spend, you have to track it, and practically nobody
> does.
>
> Consider the following:
>
> 1. Our lives are filled with interruptions.
>
> 2. Software people do many kinds of tasks, and only some contrib
> ute directly to our projects.
>
> 3. Our processes are often informal and our working practices ad
> hoc.
>
> 4. Even if we wanted to, it is hard to do demanding intellectual
> work for long uninterrupted periods.
>
> Interruptions One engineer told me she had recently
> started to track her time and found she was spending much more time on
> interruptions than on her real work. For exmple, on one task of 108
> minutes, her interruption time was over 300 minutes. Thislost time,
> however, was not in big hour-long blocks but from an
> incessant stream of little 5- and 10-minute interruptions.
>
> Interruptions come from many sources:
> * telephone calls
> * other engineers asking for help
> * a coffee or rest break
> * supply problems (i.e., printer or copier out of paper)
> * equipment problems (the network dies)
> * a power failure or a snow storm (everybody leaves)
>
> Every interruption breaks your train of thought and takes time
> away from your work. With unplanned interruptions, you lose your
> place in the work and, when the interruption is over, you have to
> reconstruct where you were.
>
> This also causes errors. For example, when I am in the middle of
> a design, I am often working on several things at the same time.
>
> While thinking through some logical structure, I realize that a
> name is misleading, a type must be changed, or an interface is
> incomplete. If I am interrupted in the middle of this, I often
> have trouble remembering all these details. While I have been
> unable to control the interruptions, I have found that
> maintaining an issue log helps me remember what I was working on
> when interrupted.
>
> Non-project work :
> non-engineering tasks. Examples are
> * handling mail
> * setting up or updating their computing systems
> * going to meetings
> * looking for some specification, process, standard, or manual
> * assisting other engineers
> * attending classes
>
> Few software development groups have adequate support. No one
> sets up or maintains his or her development system, few have
> groups to handle product packaging and release, and there is no
> clerical or secretarial support for mail, phone, or expense
> accounts. What is more, even when they have such support, many
> engineers don't know how to use it. This means that most of us
> spend more time on
>
> clerical and support work than on our principal development
> tasks. And every hour spent on these tasks is an hour we can't
> spend on development.
>
> Lean and mean organizations: Often our organizations pride
> themselves on having very small support staffs. An almost
> universally accepted management axiom is that overhead is bad and
> should be eliminated. In the resulting lean and mean
> organizations, the engineers do their own clerical work. This is
> not an effective way to use scarce and expensive software talent.
> By cutting overhead, management also eliminates the support
> staffs that funds in the overhead budget support. While some of
> these groups are not the least bit interested in supporting the
> engineers, many are. Eliminating them can have enormous costs.
> Among these costs is the time every engineer must spend sorting
> through email, answering the phone, getting supplies, doing
> expense accounts, and filing mail and documents. In addition to
> the lost engineering time, this also means that most mail isnot
> answered promptly if at all, phones go unanswered, supplies are
> wasted or overstocked, and little if anything is properly filed
> or can be quickly found when needed.
>
> Perhaps most expensive and annoying, every software engineer in
> such "lean and mean organizations" must set up and maintain his
> or her personal computing environment. Just because we have
> theskills to do this doesn't mean we should. Most of us could
> repair our cars or paint our houses if we chose to, but it would
> take us longer than using someone who does this for a living.
> And we have other things to do. Why should we have to handle our
> own computing support? The principal reasons that engineers
> spend less than half their time doing the tasks they were trained
> and hired to do is that, without adequate support, they have to
> support themselves.
>
> What is more, few engineers enjoy or are very good at being
> part-time clerks and technicians.
>
> Ad-hoc working and planning: When one has taken the time to
> define and document the organization's practices and methods,
> they must be maintained informally. When you come to a task that
> you haven't done before or at least not recently, you look around
> to see how
>
> it should be done. It takes time and a lot of interruptions to
> find someone with the right experience and get their help. While
> this is vastly preferable to bulling ahead without exploring
> prior experience, it does cut into the working week. A related
> but slightly different problem concerns planning. When projects
> don't make detailed plans, and when engineers don't know
> precisely where they fit into these plans, they must do what I
> call continuous planning. In continuous planning, the key tool
> is not the PERT chart or Microsoft Project, it is the coffee
> machine. When you finish a task, you go to your continuous
> planning tool to have a cup of coffee. While there you decide
> what to do next. In the process, you talk to any other engineers
> who are also doing continuous planning and see what they think.
> You will usually get some good ideas, but if you don't, you can
> always interrupt someone. The common view is that planning takes
> too much time. By not planning, engineers can immediately start
> on their programming work. While this immediate progress will
> feel good, you won't know where you are. Like driving in a
> strange country without a map, you have to stop at every turn and
> decide where to go next.
>
> All these short stops will take far more total time than
> aproperly thought-out plan would have taken in the first place.
> You also need an occasional break.
>
> Finally, creative development is hard work. When designinga
> product or a system, we need uninterrupted time. But we cannot
> design complex products for more than a few hours at a time. The
> same is true of testing, reviewing, inspecting, coding,
> compiling, and many other tasks. One laboratory decided to set
> up a dedicated group of experts to inspect a large and important
> product in final test. Every module that had test problems was
> sent to this group. For a while, they cleaned up a lot of
> defect-prone modules. Then, one of them later told me, they
> could no longer see the code they were inspecting Everything
> began to blur. They even saw source code in their sleep.
> Designing, coding, reviewing, inspecting, and testing are
> intensely difficult tasks. To have any hope of producing quality
> products, we must occasionally take breaks. But, to be
> reasonably efficient, and to do high-quality work, we need to
> control our own breaks, not take them when the phone rings or
> when somebody barges into our office or cubicle. Studies show
> that when engineers spend all their time on their principal job,
> their performance deteriorates. Some reasonable percentage of
> time on other tasks such as planning, process improvement,
> quality analysis, or writing papers can improve engineering
> performance. You will get more and better work done in the
> remaining 75% of your time than you would have accomplished in
> 100% of dedicated time.
>
> 1. So, keep track of your time: To manage your personal work,
> you need to know where your time goes. This means you need to
> track your time. This is not hard, but it does require
> discipline. I suggest you get in the habit of using a time
> recording log. When doing so, enter the tasks and the times when
> you start and stop these tasks, and also keep track of
> interruption times. If you do this, you will soon see where your
> time goes. Then you can figure out what to do about it.
>
> 2. Manage interruptions: Interruptions are a fact of life, but
> there are many ways to deal with them. Use "DO NOT DISTURB"
> signs and establish an ethic where everybody (even the managers)
> respects them. Forward phone calls or even unplug or turn off
> the phone. Also consider getting permission to work at home for
> a day or two a week. Another way to manage interruptions is to
> get in the habit of using an issue-tracking log.
>
> Then, when you think of something you need to do, make a note of
> it in the log so you will remember to do it later and you won't
> forget it when the phone rings. While you will still have to
> handle these issues, you are less likely to forget them and you
> can do them at a planned time. Also, use this same principle
> with interruptions. When someone calls in the middle of a design
> problem, tell them you'll get back and then make a note on a
> sticky so you don't forget.
>
> 3. Learn to use administrative support: Learn how to use
> support. While few engineers have a support staff to help them,
> many who do don't know how to use them. If you have a support
> person, think about every clerical-type task before you do it.
> Can this person do it for you? Even though it may take longer at
> first, use them whenever you can. At first the result may need
> to be redone. But be patient and help the support people
> understand your problems with their work. It will pay off in the
> long run.
>
> 4. Plan every job: Perhaps most important, learn to plan. Plan
> your own work and urge your teammates and the project leader to
> start planning. Proper planning takes time, but it can save much
> more time than it costs. You will end up planning anyway, but it
> is much better to do it in an orderly way, and not at the coffee
> machine. Vary your work You can do demanding work only for so
> long. I lose my ability to do intense creative work after an
> hour and a half to two hours. I need to stop for a break or even
> to switch to some other kind of work. Further, during these
> intense sessions, frequent short interruptions offer no relief.
> It then takes an extra effort to reconstruct my thought process.
> What I suggest is to intersperse various kinds of work throughout
> your day. Do creative work when you are most fresh and
> productive and then switch to your email or an administrative
> task. Then perhaps do a design or code review possibly followed
> by a process-improvement task or data analysis. By varying the
> task types, your creative work will be of higher quality and you
> will actually get more done.
>
> 5. Define and use a personal process When you regularly make
> plans, a defined process will save a lot of time. The process
> provides a framework for gathering historical data and a template
> for making plans. And, by using historical data, your estimates
> will be more accurate. Get and use historical data Finally, if
> you don't have administrative or technical support, use your time
> log to see what this lack costs you. Then tell your managers and
> show them your data. It might help them see the cost advantages
> of adequately supporting their engineers.
>
> Remember that the amount of work you produce is principally
> determined by two things:
>
> 1. the time the tasks will take
> 2. how much time you have available for these tasks
> To manage your work, you must know where your time goes.
> Only then can you judge how much work you can do and when you will
> finish it.
>
> Acknowledgements In writing papers and columns, I make a practice
> of asking associates to review early drafts. For this column, I
> particularly appreciate the helpful suggestions I received from
> Dan Burton, Alan Koch, and Bill Peterson. In closing, an
> invitation to readers In these columns, I plan to discuss
> software issues and the impact of quality and process on
> engineers and their organizations. I am, however, most
> interested in addressing issues that you feel are important. So
> please drop me a note with your comments and suggestions. I will
> read your notes and consider them when I plan future columns.
> Thanks for your attention and please stay tuned in.
>
> Watts S. Humphrey
> [EMAIL PROTECTED]
>
> Notes
> 1. For a brief discussion of this issue, see my book
> Managing
> Technical People, Innovation, Teamwork,
> and the Software Process,
>
> Addison Wesley, 1997, page 186.
>
> A more complete dcussion is in Donald C. Pelz and Frank M.
> Andrews,
>
> Scientists in Organizations:
> Productive Climates for Research and Development,
> Wiley, 1966, pp. 56, 65.
>
> 2. Recording Log, see my book A Discipline for Software
> Engineering, Addison Wesley, 1995.
>
> This log is also discussed in Introduction to the Personal
> Software Process, also by me and published by Addison Wesley in
> 1997.
