CSE403 Software Engineering Autumn 2000

Project Management

Gary KimuraLecture #10

October 16, 2000

Today

• Understand that there are different approaches to project management for software

• And what several of those are• Offer alternative and guidelines for your class project

– You’ve seem to be doing pretty good for the first three weeks– Is this because I pre-suggested a team organization or because

you’re all great organizers by nature?

• Managing schedules

Project management

• What percentage of the effort to date has been spent writing code?

• What percentage has been spend working through requirements and design?

• What percentage has been spend in meetings?• When does the real coding start?

Problems with managing projects include

• Figuring out and coordinating schedules• Handling communication among the team

– The figure shows a rough notion of the cost of team communication– The theory is that about 25% of each group's effort is spent in

communication, with this cost applying recursively– As Brooks observes, the worst case of this is adding people to a late

project, which tends to make it even later• Making decisions• Recording decisions• Managing egos• What else?

Team structure

• Brooks talks about the desire everyone has for a small, sharp team

• 10 or fewer people• All of them brilliant• All of them focused on the task at hand• But he observes that this is too slow a way to build a really

big system• And rightly so…

Why? Time

• Brooks: take a 10 person team composed of people all 7x better than the worst

• 5x to 25x are within known ranges• Assume OS/360 was built by the worst• Assume a small team has a 7x communication benefit• Assume no turnover of the team• Assume 5000 person-years for OS/360 10 actual years for the task• Now, do the same estimates for NT 5.0 with 60,000,000

lines of code!

Chief Programmer Team

• An alternative idea is to restructure a classic big team to get the benefits of the small, sharp team (ability and focus) with the benefits of a bigger team (overall speed)

• The key is to design the positions on the team very carefully

Y2K

• Most of these specific (lower-level) job descriptions are clearly out of date

• “…a team will rarely need its own machine and operating system crew”

• “All computer input goes to the clerk, who logs and keys it”

• But the idea of focusing on how to break up the team into well-defined jobs is, of course, still extremely pertinent

Chief Programmer Team

• An underlying theme of this approach is that a smart person understands the domain and defines an appropriate architecture

• Then the subpieces are spawned off to people who are talented programmers but who have little (or less) knowledge about the project

• In practice I wonder if this works very well at all– Need commitment and buy-in from all parties– Need to build team synergy

Aside: outsourcing

• Over the past years, there has been an increased interested in outsourcing significant pieces of software projects

• In particular, the interest has been to use cheaper labor in places like India, China, Ireland, etc.– There is a big political issue related to this, which is the question

of granting H1-B visas to people from other countries to work in high-tech in the U.S.

• This in many ways resembles aspects of the chief programmer team — “Give them the spec and let them code!”

More on outsourcing

• A serious problem with the outsourcing version of coding is the increased distance between the programmers and the people who own the requirements

• Communication is almost entirely by email, travel is costly and time consuming, etc.

• I believe this leads to less and less effective communication, significantly increasing risks

Team structures I’ve been involved in• DECwest Compiler team

– About 6 people– One language architect and manager– Two senior developers– Three junior developers– Documentation and testing?

• Overall NT team at Microsoft– When it began in 1988– When NT first shipped in 1993– When I left in 2000

• The NT file system team– In its most productive phase there were 4 developers, twice as many testers, and

everyone eating dogfood.– Later it had over 20 developers (not by choice)

Some Microsoft job titles• Program Manager

– Maintaining the big picture. Weighing risks against costs. Understanding many disciplines. Keeping a variety of specialists on the same page. Sewing all the components of a project together to make world-class software projects happen on time, on budget.

• Software Design Engineer– Working with other product team members from the beginning of the

product cycle through release, our SDEs design and implement sophisticated products ...

• SDE in Test– Deeply involved in every phase of the product cycle, our SDEs in Test

devise and implement test plans and strategies. … It's a specialized skill that requires the ability to effectively second-guess our other developers.

• Software Test Engineer– As the strongest advocate our end-users have, Microsoft Test Engineers

develop and execute test plans and scripts designed to detect problems and ensure the quality ...

Last years team structure

• Fairly non-hierarchical team structure• Small teams (5 students)• Nobody was really the boss• Everyone can communicate with each other• Would not scale well to larger teams (even at 10

people it falls apart)

This years team structure

• Hierarchical divided up into specific areas• One assigned manager (coordinator) for the whole team• Each sub-team works “quasi” independently of the other teams• But communication and buy-in by everyone is still a must• A way to make decisions needs to be agreed upon• A very common problem is to fight for a long time over

decisions for which either alternative is adequate; often, making a decision is more important than which decision is chosen.

• Most often a good manager is the decision maker if consensus cannot be reached in sufficient time

Decision making

• Making decisions is something we do all the time in a project

• The biggest risk, in general, is not that we make a bad decision

• It is that we delay making any decision past a point of no return

• You should probably spent relatively little time deciding between two pretty strong alternatives

• This is perhaps especially true in your project, given the incredibly compressed schedule

Recording decisions

• In your meetings you will be making a lot of decisions• Some you’ve probably already made are who will do what,

what will the requirements be, who will write up what, what coding standards (if any) will we use, how will we name our variables, etc.

• You might even still have some major design decisions to work through.

• You cannot record all your decisions in writing…but you’d better record the key ones! Decide where these are recorded and how.

• How have you been recording and keeping records?

Running meetings• You’ve already had a few meeting, let me just offer a few tips

if I can• Have an agenda• Have a person responsible for keeping the meeting on the

agenda• Have a person record key decisions• This person can rotate or can be assigned to someone who is

good at this by nature• Show up to the meetings (uh, and classes)• Start them and end them on time• It may be that your team’s ability to succeed is driven as much

by things like how your meetings run as by how well you cut code

Artifacts

• The following are two documented/analyzed ways to aid in managing projects

• You may find these artifacts helpful for your project management task

• Some, of course, may appear in your actual project, as well• As always, (a) use what you want and (b) don't over do

anything!

The primary example is a Gantt chart to show the link between tasks and time

• A Gantt Chart maps tasks to dates• There is a row for each task; the columns represent dates• This makes it easy to see the schedule• So it’s often a good way to build an initial plan, to view

the schedule, and to make adjustments• Task linking is a constraint that says, “Task x cannot start

until Task y completes”• I use to use a white board with yellow sticky notes for this

purpose but also with developers

PERT charts• Displays tasks and task dependencies as a network

diagram or flowchart• A node represents each task and a line connecting two

boxes represents the dependency• There are some nice software packages that help with, but

personally, I can’t stand them

“Software engineering is not a mere matter of programming”

• Coming up next– Individual project reviews– Testing, testing, and more testing