Would you like to make this site your homepage? It's fast and easy...
Yes, Please make this my home page!
Manager's Compendium
For Software Engineering
CSE308/CSE309
TABLE
OF CONTENTS
1.0 Introduction
1.1 Why You Were Selected
1.2 What Kind of Job
is Required of You
1.3 What Sorts
of Powers are Given Onto You
2.0 Inner-workings of the Group
2.1 Pick the Right
People for the Right Job
2.2 Communications Within
the Group
3.0 Managing the Project
3.1 Selecting the Project
3.2 Writing the Documents
3.3 Writing the Codes
Credits
1.0
Introduction
Congratulations! If you are reading this Manager's Compendium
then you must be among the privileged few who were voted, out of their
teammates' confidence, to be their leader in this one-year software engineering
project. Only the managers with enough sense of responsibility, leadership,
and most of all, courage, will make instead of break their team in the
upcoming project.
Throughout this Compendium you will be offered to you many advises as
it can be safely assumed that most of you have not led a medium-sized programming
team of this size in a medium-sized software project of this scale before.
In the probable event that you have, my best wishes to you and you can
promptly skip the next fifteen pages. Otherwise, read on!
1.1
Why You Were Selected
As previously emphasized, the managers play an essential role in the
success of the team that they manage, therefore it is very important to
decide who should fill the position of manager. It is trusted that in every
group there is always at least one person able and willing to become the
manager of the group. There is no extra credit for being the manager; there
is no grade modifier for being the manager. One is selected to be the manager
precisely because he/she is hardheaded enough to do all the extra work
and take on all the extra responsibilities for no extra grade.
Why would anyone in his/her right mind be so foolish as to accept such
a position if that is the case? Here is a list of three basic reasons:
- Prepares the individual for future commitments as software project
manager, or for that matter, in any sort of management position. Graduates
from this class have gone on to become real-world managers and come back
to talk about their experience here(ask Prof. Lewis for details)
- Provides excellent practice for multi-programmer programming projects.
Since in the industry one rarely programs alone, it is good to become accustomed
to this practice as soon as possible.
- Serves as an attractive resume item. It is also extremely impressive
to bring alone the portfolio you will build throughout the year(documents
such as the Product Proposal Document and the Specification Document)
1.2
What Kind of Job is Expected of You
Words of wisdom from one Flower A. Newhouse, a twentieth century Christian
mystic -"Lack of will power has caused more failure than lack of
intelligence or ability". Willpower, provided with lots of caffeine
will see you and your group through the project that is ahead of you. As
the group manager, you are expected to stay awake when everyone else is
asleep, stay focused when all others have lost concentration, and most
of all, stay positively encouraging when the entire team has lost any possible
hope of completing the project.
As the student manager, you will be expected to make sure that:
- All documents/codes/executables/webpages etc. get done on time and
as per their specifications. As the year goes on this task will be increasingly
difficult, the advise here is obviously to start way, way, way before the
deadline.
- All programmers in your team get their share of the documents/codes/executables/webpages
etc. done. Note that this task is not necessarily the same as task #1 since
many a manager has been forced to complete whatever assignment that was
not completed by his/her teammate(s) alone by him/herself. DO NOT LET
THIS HAPPEN TO YOU TOO!
- The group works harmoniously without conflicts. Since in all likelihood
there will be disputes concerning the fairness of assignments etc., it
is your responsibility to resolve the conflict. Because if you don't, nobody
will.
1.3
What Sort of Powers are Given Onto You
"It is much more secure
to be feared than to be loved" - Niccolo Machiavelli, the great
Italian political and military theorist of the sixteenth century. DO
THE OPPOSITE! From the author's personal experience of two semesters'
managing, it is definitely worse off to be feared. Do not misuse
your powers as the manager, if the mutual trust in the group is broken,
it is like the broken clock - "you can mend it but you ain't gonna
fix it."
As the student manager, you have the following powers:
- Deciding the amount and difficulty of responsibilities assigning to
each individuals of your group. Do this wisely, as there will be times
when you will wish you have more manpower/womanpower, when that happens
think back and you will almost always realize a better assignment distribution.
- Deciding the group schedule for the entire one-year period. It is of
utmost importance to arrange for a consistent meeting schedule, so that
your people get used to meeting and discussing at a regular basis. Only
an incompetent manager schedules nothing for a month, then an overdose
of meetings just before a major assignment due date. I guarantee you the
work will not get done.
- Deciding the exact content of the final version of any document. This
is really an important responsibility/power since any error/flaw in the
document will cost a possible grade deduction of you and your entire crew.
- Deciding whether or not to file a complaint on anyone of your teammates.
While it is unfortunate, it sometimes becomes necessary to notify the professor
of extreme uncooperativeness of a fellow teammate. Perhaps he/she will
receive a different grade, perhaps he/she will be discharged from the team,
different outcomes result from filing a complaint. Be sure to be able to
back up your charges and most of all DO NOT ATTEMPT THIS UNLESS IT IS
ABSOLUTELY NECESSARY! You do not wish to end up alone doing the project.
2.0
Inner-workings of the Group
In this section advises will be offered to you regarding some of the
strategies/tools in managing the group of programmers at your disposal.
This part of the job is the heart and soul of management and chances are
if you accomplish this portion of the job everything else(coding etc.)
will follow.
Section 2.1 offers pointers on how to assign the individual tasks to
different member of you group.
Section 2.2 offers different methods of communication that may prove
useful in your team management.
2.1
Pick the Right People for the Right Job
Obviously, the strength of a programming team depends heavily on the
quality of its personnel. A good manager, however, can always make the
best out of anybody, regardless of ability. As the year goes by you will
invariably notice the weaknesses and strengths of your teammates. Here
is a list of pointers from different managers:
- Distribute tasks according to each person's ability, but make sure
everyone has something to do. The worst thing you can have in your team,
equivalent to the mob of Rome, is people with nothing to do. (Note: it
is different if someone has done a superb job and you decided to let him/her
take off a couple of days) Usually when a member of group finds him/herself
with nothing to do, he/she slacks off in other respects of the project
as well(ie: stops coming to meetings, lectures etc). Furthermore, nothing
beats the gratifying experience of accomplishing a project in which everyone
participated, regardless of the type of work each one performed.
- Be sensitive to each person's ability and interests, and whenever possible,
assign the workload as such. Sometimes there will be individuals who express
a special affinity to certain type of tasks. For example, one person may
be adept at spatial art, such as webpage design or interface design for
the program. Do not hesitate in giving him/her a big chunk of the upcoming
webpage or interface construction, he/she will appreciate your noticing
his/her ability and you will be certain that the job is in good hands.
- Always be ready to pick up where anybody leaves off. Sometimes accidents
do occur, and if it becomes necessary to finish someone else's work, do
not hesitate, this sort of extra work comes with the job. Once you have
demonstrated that you are capable of safeguarding the project in crunch-time,
you will have more respect from the group. Obviously you do not wish it
to become a habit for the rest of the team to time-after-time rely on you
to do their work. Hopefully the people you picked to work with you have
enough self-respect to prevent that situation from happening.
- Find your best guy/gal as soon as possible, and make sure that he/she
has just enough work to keep him/her busy, but not so much work that he/she
will be completed occupied. Chances are you will need this "wild card"
to save your behind in crunch-time. Be in good terms with this ace of yours
and know his/her areas of specialty, let him/her know that you depend on
him/her for important tasks, he/she will appreciate that.
2.2
Communications Within the Group
In this section various tools of communication will be suggested to
you. There is a good chance that you may not be familiar with all of your
teammates, and even if you are, the conventional way of communication by
telephone or chancy rendezvous at the campus simply will not work in this
case. Here are some tried and true methods of communication:
- Email group. Easiest way is to set up an email group so that when anyone
replies to the group, everyone in the group receives a copy as well. The
advantage of doing it this way is that important messages/documents/codes
will go to multiple storage locations. Use a separate mailbox if possible,
since the mailbox will be "flooded" with message from your group.
Announce meeting time, current goal, etc. on the email group, so that there
is always that last source of information which people cannot simply claim
that they "forget".
- Website. If you have the necessary skills or if one of your teammates
does, have a website up and running with the latest information as well
as documents of the past. If it can be automated to show personalized assignment/schedule
information for different person, so much the better, but it really does
not have to be elaborate, it is simply a great place to hold references
that can be easily accessed.
- Multi-user domain. Does not have to be an actual M.U.D., but any sort
of multi-user chat room is fine. There are freewares out there currently
such as the ICQ system from Mirabilis(www.mirabilis.com),
or you can set up a chatroom somewhere in IRC. This may substitute some
of your meeting time if a common time slot is simply not available, but
from the author's personal experience it is still very important to hold
face-to-face meetings at least once a week.
3.0
Managing the Project
In this section more advises will be offered on the development of the
actual programming project. The project itself consisted basically of three
phases:
- Design Phase. This is when the entire group is brainstorming for applicable
and original ideas to implement. The major documents: Project Proposal
Document, Specification Document, and the Design Document are to be written
during this phase.
- Implementation Phase. This is when the body of the programs actually
gets implemented. Theoretically if the Design Document and the Specification
Document were written in a concise and specific manner, this phase would
simply be a matter of taking each small component from the documents and
translate it to code. In reality it is most likely the case that modifications
must be made to the original plan in order to produce a practical version
of the program.
- Test Phase. This is when the program is being tested to match the final
versions of the Specification Document and the Design Document. A Test
Plan must be drawn out to efficiently utilize the time allocated.
3.1
Selecting the Project
The very first thing the programming group must accomplish is the decision
of the project goal itself. What shall be implemented? What shall the program
do? This is usually the second most exciting time in the entire one-year
period(most exciting time being at the end when the project is actually
done). This is a good time to utilize the communication methods mentioned
prior in section 2.2. Besides the time the group spends together in the
weekly meetings, the manager(you) should bring enough enthusiasm and energy
into the project itself that the group members will find it exciting to
go out on their own and bring back ideas to the group. The website would
come in handy where ideas can be deposited and displayed. The email group
can also serve the same purpose in this regard.
An upstart team at this stage of the game usually gets too excited and
weaves a goal too complicated for a practical programming project in one
year. Remember this - strife for a programming goal that can be coded in
less than three months.
3.2
Writing the Documents
Before the first line of code is written, three major documents must
have been written and revised - the Product Proposal Document, the Specification
Document, and the Design Document. There is no set way of structuring these
documents. One common practice, however, is to number each sections in
nested bullets. That is, suppose the Introduction section is number
0, then the Overview within the Introduction would be 0.1, the Purpose
would be 0.2 etc. This system gets real handy later on when one must refer
to sections within the same document, or to sections contained in another
document. If it is feasible, translate the documents into Internet accessible
form(html, pdf etc.) so that any member of the group can easily look it
up in the future. THIS IS ESPECIALLY USEFUL DURING THE CODING PHASE!
Of course, it will be a pain if the method for version control is not efficient.
Graphics are definitely a plus, so are the final touches such as the
binding of the document and the title page of the document. If feasible
assign one team member and give him/her a few days to work out the best
way to present that particular major document. As previously mentioned,
this sort of documents can and will become invaluable items in your portfolio
which you will feel proud to show to anyone, any time.
3.3
Coding the Project
So now your group has gotten together all the major documents and the
final goal has been carefully planned out, all that there is left now is
just coding, or is that all? Whereas the previously experience thus far(approximately
1.2 semesters) prepares and paves the way for a systematic way of working
in group, the coding phase is when the team actually begin to appreciate
those documents it wrote prior. It can be one-hundred-percent guaranteed
that the final product will be somewhat different than originally planned.
There are more than three programmers programming, something is bounded
to go wrong! Here is a list of methods that worked well in the past:
- Start the group coding sessions as early as possible. Group coding
sessions are when some or all of the group code in a centralized area where
communication is easy and data transfer is fast (for example, the ug lab)
Extra job for the managers : before announcing the group coding session,
you must know exactly what must be done. Have the exact goal for that particular
coding session written down somewhere(for example, the email group) and
let everyone who is coming know about it.
- Talk to each member of your team before assigning tasks. Each of them
must verbally agree to complete the task in a given date.
I cannot stress this enough. THE DEADLINE WILL BE EXCEEDED! But
if you have them verbally agreed to, say two weeks before the deadline
set by the professor, then you have a better chance at completing the project
just in time! Be lenient in giving extensions(given that you have already
set the deadline at least weeks before the actual deadline), but always
make the deadline your teammate agreed upon official.
Credits
The author - David Li is currently a senior majoring in Comp. Sci and
E.E. in S.U.N.Y. at Stony Brook. His software engineering group completed
the NutriCenter system which allows the user to keep track
of his/her nutritional information in his daily food intakes via a barcode
scanner and an Internet database(currently only accessible within the Transaction
Lab). His group did not get an A in the second semester, however, because
he ignored the warning covered in section 3.1. He can be reached via email
at davidl@ug.cs.sunysb.edu
Since July 7, 1998
Back To David Li's Home
Page