Software Engineering Tenets

I usually find that with four people, if one of them, like your team leader, starts rewritting everyone''s code, then you can compansate by assigning someone else the job of SQA/code review...., so that way he would be stepping on someone else''s toes...usually that puts people like that in there place...

That works about 1/2 of the time, the other half, you just have to fire them, it will cost the project if they continue ANYWAYS, so you might as well endanger the project by letting them go..

I feel there are two questions in your post: one regarding software engineering and one regarding project managering. I will adress the second question since I am myself a project manager.
Curiously enough, a project manager main task is not to product code. If the team is small enough (like four persons) the project manager may take for him-/herself some tasks to do but this should not be his/her main priority.
A project manager main task is to ensure the project to be completed within a time frame: he deals mainly with people.
A project is defined by a defined goal, a beginning date and an end date. The project manager must:
- define with his/her team the tasks necessary to complete the project, (study steps, coding steps, testing steps)
- define with his/her team the order of the tasks,
- assign for each task a person from the team.
This is simply a planification phase where subgoals and dedicated persons are defined - note the coding has not yet even begun. Thus planification is the first concern of a project manager. He/She has the full picture of the project, he/she should not burden him-/herself with tasks (unless he/she has not enough team members regarding the project to do).
To be able to check everyone advance and to ensure a minimum (and I said minimum not total) coherence in the project coding, the project manager defines with all the team members a set of coherent coding rules so that everybody can be able to read at each other code and to be of assistance.
When the project is under way, the project manager must check regularly with each member of his/her team what are the subgoals that are not yet achieved and the reasons behind it. If the team member is blocked, it is the duty of the project manager to solve the problem. The project manager is responsible for the correct advance of the project.
The project manager is accountable to the end-user. He/She gets the end-user required functionalities and the end-user set of constraints. He/She must regularly tell the end-user what is done and what is left to do. He/She also has a duty of advice to the end-user to help the latter define what is feasible and what is not.

As you can see, the primary concern of a project manager is the end-user satisfaction and the optimization of the team work flow to satisfy the end-user requirements. The project manager deals with people before dealing with code.

To sum up:
I would define the tenets of a good project manager to be:
1 - strong listening ability
2 - open minded
3 - dedicated leadership (motivates the team and ensures that everybody does his/her tasks within the timeframe)
4 - resourcefull (to be able to find solutions to team member blocking problems)
5 - knowledge of people characters (to be able to find the best person suited to each task)

I would define the responsibilities of a good project manager to be:
1 - planification of the project and resource allocation
2 - management of the project (advance checks, team motivation, blocking problem solving)
3 - end-user advisement
4 - end-user communication (project advance by example)

Now check your team leader qualities against the qualities of a good project manager. To your mind, was he up to it ?

Regarding leaders, Han Fei Tseu used to compare them to dishes: when you pour water in a square dish, the shape of the water is a square. When you pour water in a round dish, the shape of the water is a circle. Thus the team member shapes his/her team (meaning good team leaders make good teams, bad team leaders make bad teams and the team abilities have nothing to do with it).

Hope that helps,
Ghostly yours,
Red.


[edited by - Red Ghost on October 9, 2002 12:24:21 PM]

I worked on a team that essentially had to create portions of what has become Outlook 2000''s calendar system in Unix. We had 5 people. Three coders, one person who did nothing but documentation, and a team leader who did QA and helped document stuff.

We had previously learned that the guy we assigned to document had lead another team into the ground, so three of us determined that he was going to do nothing but document the project instead of code. We simply weren''t going to risk it, considering the tight deadlines and monster features that were needed.

In the end, having just three of us write code worked out better than having four or five. One of the coders came to me late in the project and said he simply couldn''t finish his portion because he didn''t know what he was doing. I kind of took over for him, and he helped me understand what needed to be done for his piece as needed, so I did his work in addition to mine. Since mine had already been done, I completely understood what was going on.

A side bonus to having a small team like that is that you generally have a good idea of how everyone else''s pieces are supposed to work. With one person, it''s easy. As you add people, you become less knowledgeable about the other pieces because you''re not working on them.

I guess my point is, know your team members, their abilities, and their LIABILITIES. The last one is key. I''d prefer to know someone''s weaknesses up front on a project rather than their strengths, as people are a lot more willing to tell you what they''re good at rather than what are their personal drawbacks.

Something else that hasn''t been explicitly mentioned here is that the ability to program does not equate to the ability to lead a programming team. Someone I worked with was a very good programmer. He knew his stuff cold, and I mean cold. He could do it blindfolded. But at the same time, his code was impossible to read or maintain. Nobody could figure it out. Eventually, he was removed from the team lead, and later fired for his inability to work with others.

Just because someone has 20+ years of programming experience, doesn''t mean they are a good choice for a programming lead. As already mentioned, the team lead should be a people person. Not necessarily a great programmer. You are relying on his ability to make good team decisions. Not good programming decisions.

---

Looking for an honest video game publisher? Visit www.gamethoughts.com

Try setting up formal review sessions for QA. It''s actually a pretty simple process. Here it is, but you can find lots of info about the formal process on the web.

1. You all meet to go over a document (someone''s code).

2. Important positions are
Moderator - Keeps the meeting on track.
Author - Creator of the document.
Reviewers - Everyone else.

3. Everyone should have reviewed the doc before the meeting.

4. Everyone goes over the issues the found in the doc.

5. Everyone has a say in the seriousness of the "issue", so BS issues are dropped right there. Also the only person who changes the document is the "Author".

If you run these meetings pretty well, you can accomplish a lot, and you can keep the primadonna garbage away from the project. Also you don''t want the primadonna to be the moderator.

quote:

---

Original post by DeltaVee
I, and I believe pretty much every SE, practice the following:


The 3 Cardinal Tenets of Software Engineering

Tenet 1. Keep It Simple
Corallary: Don''t build a suspension bridge to ford a puddle.

Tenet 2. If it isn''t broken then don''t fix it.
Corallary: Don''t rewrite code based on aesthetic principals.

Tenet 3. There is always more than one solution.
Corallary: Don''t assume that your way is the best way.

---

I can''t wholly agree with 1 and 2. (3 is fine.) My objections come down to the same thing, really - sometimes ''good enough'' is not ''good enough''. Very rarely have I ever seen any non-trivial class or API written where new functions were not added to the interface later. Sometimes existing functions needed to be changed or replaced, and occasionally stuff needed ripping out entirely. This is because humans are not perfect and can''t predict everything. But sometimes they can predict some things, and it makes sense to expend some effort in catering to that, because 5 minutes spent now could save 5 hours later. Refactoring is a key example of this principle at work - if you see that something works, but is getting close to being unmanageable, see if you can spend a little time making it manageable. The only problem is how much time you spend on it. Too little, and you regret it later. Too much, and you''ve quite simply wasted time for nothing. Sadly, I think that being able to make this decision well is something you will only get with practice and experience.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

quote:

---

Original post by DeltaVee
The 3 Cardinal Tenets of Software Engineering

Tenet 1. Keep It Simple
Corallary: Don't build a suspension bridge to ford a puddle.

Tenet 2. If it isn't broken then don't fix it.
Corallary: Don't rewrite code based on aesthetic principals.

Tenet 3. There is always more than one solution.
Corallary: Don't assume that your way is the best way.

---

I do not totally agree with 2. It seems to me that your team is suffering from a lack of coding standards.

If a team member doesn't make his code const safe or exception safe, the code quality of the whole project suffers. Just because one programmer. It would be better to fix the code even though it works. I certainly wouldn't call using STL asethetic.

I applaud at your team leader for being a STL evanglist (me myself being one too). I'm sure he has kind intentions in mind - code reuse, efficiency. Since your team has a lack of expertise in that area, more time should be allocated to training. # of years experience is an poor indicator of skill level. I could be programming C for 10 years and yet know nuts about OO design.

I had done a few projects (mostly solo) that I use STL and boost. My project lead told me to avoid STL. Reason? He doesn't understand it. Am I given more time to write my link list? No. Now there's a real lack of respect coming.

Good judgement comes from experience. Experience, comes from bad judgement.

EDIT: I realize I said NOT to avoid STL when I meant AVOID STL.



[edited by - void on October 16, 2002 11:35:01 PM]

quote:

---

Original post by DeltaVee
The Team leader, a person for whom I had great respect for, made a mountain out of a mole hill, re-wrote every ones code, and pretty much frustrated everyone with his STL evangelism.

---

Could you provide examples of the 'STL evangelism'?
To a certain extent I would have to agree the with evangelist. There's not much sense in writing your own dynamic array, list, or map - or even using one you're already written, given the widely available standard containers.
Now if he insisted that everyone use a practically functional style of programming and numerous adaptors to force code through standard algorithms, I can understand your grief. I can see how that could easily be counter-productive.

I can't see how rewriting everyone's code was even a feasible task though. Did he just replace the hand-crafted containers with STL ones? or start from scratch?

The tenets you list are important, but they're also used as justification to do the crudest thing that barely works. Software architecture tells that conceptual integrity is the most important aspect of the architecture, and crude things that barely work do not have much conceptual integrity.

I recently made a change to a library I'm working on, where I changed the name of a typelist function from GenData to IterateTypes. Technically it was a cosmetic/aesthetic change, but the new name is so vastly superior it's embarrassing that I ever used the former

[edited by - Magmai Kai Holmlor on October 16, 2002 10:58:34 AM]

I''ve had a number of people tell me that I was too worried about aesthetics. These people usually wrote unreadable code, had deeply nested inheritance hierarchies, and were more concerned about some ''abstractness'' goal than getting the project done. Others have proclaimed their love of documentation, when that really meant that their code was unreadable and their architectures convoluted, and the only way to find some random feature was to grep through the documentation. Some of these "software engineers" demanded respect because they have a lot of years of experience. I believe that headers should communicate the design and use of classes. Hide clutter, group the interesting bits together, use names that are concise and descriptive /in context/, use a readable naming convention, align member names for easy reference, etc.

Principles are easy to agree on; it''s applying them to specific situations that requires experience and good judgement. =)

1. Don''t build suspension bridges, but don''t do the bare minimum, either. Be wary of future changes and additions.

2. Refactor broken designs. If you have to spend time learning a system that could benefit signifigantly from refactoring, go ahead and clean it up while you are there.

3. --

-Hierophante

quote:

---

I believe that headers should communicate the design and use of classes. Hide clutter, group the interesting bits together, use names that are concise and descriptive /in context/, use a readable naming convention, align member names for easy reference, etc.

---

I used to agree with the header theory, but I''ve been moving away from it the last few years. I still try to make the headers pretty concise, but I''ve found them to be less and less my main source of documentation.

I''ve been using doxygen for the last few years. At first, the extra space created from the documentation comments bugged me because it obscured the larger structure of the header. Since that time I''ve had to hop into 3 or 4 projects that were well underway. I found doxygen to be enormously helpful in reverse-engineering the code. The source was pretty useless in those projects. Being able to quickly walk hyperlinks in the browser made figuring stuff out so much easier. Now, I''m used to looking through documentation separate from the headers. It''s not really that different than using MSVC online help to look up Win32 reference material.