On Sat, 2012-06-02 at 20:46 +0530, Arun Khan wrote:
On Fri, Jun 1, 2012 at 4:49 PM, kenneth gonsalves
<lawgon at thenilgiris.com> wrote:
... snip ...
I will share my experience at a prop. software shop (Bell Labs).
3. The design is then sent to production. The job is parceled out toI
several teams, each team working in isolation from the other teams.
will not go into how these teams operate, but the general atmosphereis
- if it works, it is fine and peer review and criticism of another's
code is seen as a deadly insult.
Every developer had to write a high level design document (interfaces,
db, real time requirements etc.) which got broken into Design Units
(Code). The DU doc had pseudo code and/or flow charts showing how each
C function would work.
Each document was reviewed by peers and senior members. The document
would not be accepted until major/severe bugs were resolved. Ditto
with DU - Code could not deviate from that mentioned in the DU docwent
through inspection and walk through by peers and module owners.
Again, code not be submitted for integration until all errors were
resolved. This does not mean that the entire system was bug free but
the philosophy was to catch as many bugs before they crept into the
system.
Obviously a lot of the code isone
duplicated as no team knows what the other teams are doing, and, no
will anyway admit that another person's solution is better than his.the
Note that the teams do not have any contact with the clients. When
teams finish their assignments, most of the members move on to other
projects leaving a skeleton team to cope with the next stage.
Every developer had access to *all* the code in *all* the sub systems
- no code duplication. Peers suggested code improvements during the
inspection stage (I learnt a few tricks in C from peers this way).