Thoughts on Team

(1) Recently comtemplating on team allocation in response to sometimes unexpected staff turnover.

I hold the "all or none" view over the resource allocation, 50% parallelism in my opinion rarely works out well and is a potential contributor of delays in projects -- not very focused, and slippage on one task results in the other task slipping as well. This is schedule wise.

Personnel wise, worrying two things at a time and performing mind swapping is a big productivity denominator. Particularly, software engineers in fact are the most stressful roles in the entire team facing constant deadline, 50%+50%>100% is a reasonable math equation here. It is possible unless at one side to only perform some comparatively less stressful functionalities, such as meeting customers, writing technical documents etc, and if the person prefers such exposure.

But on the other hand, mutual backup is always a good thing. If only a single lone worker, with or without supervision, would have little enjoyment and could hardly strive - "no man is an island". Not to mention the weight of stress. And this also suggest the need and difficulty to avoid and mitigate single point of competence.

(2) About System Design, Implementation Design, Share of Responsibilities among Team Members

"Software implementation is a creative activity of the first order - architecture, design, is not more creative work than the designing of implementations. It is just different creative work." -- Mythical Man-Month

My thinking: Often due to the absence of unbreachable boundary between the two groups of people, one of them might happen to be the same person and the lowest common denominator rule applies.

(3) About Oversight, Peer Validation and Roles of Team Members

This is my thought: Computers do what you told them to do, but not what you intended them to do.

The nature of work for design engineer is to have critical thinking at a macro level, perform abstraction and have selective ignorance. The nature of work for software engineer is to have critical thinking at a micro level, for the attention of details and careful oversights. We could only perform selective ignorance if we know the array of details to choose from and to abandon away, and the consequence of ignorance. In a project without competent software engineers, we could only have wings made of wax and feathers like Icarus, burning away when being too close to the sun.

[P.S. I tried to thinking of good examples, which are usually associated with feeling of "common myths". ViewState popped into my mind. Take a look at this article: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx. Quote :

"MISUNDERSTANDING OF VIEWSTATE WILL LEAD TO...

1. Leaking sensitive data
2. ViewState Attacks - aka the Jedi Mind Trick -- *waves hand* that plasma tv is for sale for $1.00
3. Poor performance - even to the point of NO PERFORMANCE
4. Poor scalability - how many users can you handle if each is posting 50k of data every request?
5. Overall poor design
6. Headache, nausea, dizziness, and irreversible frilling of the eyebrows." ]

These might be a little far-feteched but it is indeed very possible to happen. It could be seen that any carefully weaved architectural decisions or fulfillment of non-functional features could be easily defeated by the weakest link; usually being overly devoted to top-down approach, architecture designs are better to be injected careful and metriculous bottom-up examination - which requires experience gained from past experience or "getting the hand dirty for now" or at least have an assistant who is capable and willing to do so. In fact, sidetracking, most of debate on "architect should write code or not" should really come down to question phrased differently: "is architect able to see the details in coding" and "is architect willing to write code when necessary to (communicate)".]

There is always certain lag in prestige or implied paycheque between design engineer and software engineer, or between who designs and who implements, which consequentially drives the supply of both. In fact, a good software engineer could save a failed design engineer. A good design engineer is too early to save a failed software engineer. To be a good design engineer, he/she must be a good software engineer first, or often, they are the same person and again, the lowest common denominator rule applies.

The test team should have the best software engineer to provide oversight - therefore, tester should never be considered or projected as second-class citizen in a team.

(4) About Productivity, Value Generation, Cost and Team Grooming

This is others' thought: "Most managers do not have the guts to tell a hard-working person that he is incompetent. Truth be told, many of the programmers we look upon as incompetent probably possess the capacity to be competent, but never realize that they are doing anything wrong because no one takes the time to correct their ways" -- Erik Engbrecht