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:

  1. 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)
  2. 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.
  3. 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:

  1. 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.
  2. 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!
  3. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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".
  2. 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.
  3. 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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.
  2. 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