The paper “Big ball of
mud” (Brian Foote, 1999) reminds me of
the time of working crazily, working late and sometimes overnight to clear a
big ball of mud created by other team. It happened when I worked as an software
engineer in Vietnam.
In that team, although
the design is clear and detailed, some programmers created problems by not
totally follow the design and coding standards. To meet tight deadlines (which
might have been estimated too little due to lack of knowledge in estimation
tools), programmers wrote “throwaway code”. They might have promised with
themselves that they will change it later, but they never did. The problems
were compounded as other programmers mimicked the practices, and some of them
intentionally left them company, which led to the situation that one person,
though did not understand anything of the mud his former colleagues created,
has to take charge.
Surprisingly, this is
the solution from my manager: He moved experienced people from other project to
re-structure and re-factor the program. What he did actually against Brooks’s
law: “adding manpower to a late software project makes it later” (Brooks Jr., 1995)
Brooks’s law is a
principle in software development regarding manpower and time. It was coined by
Fred Brooks in his 1975 book The Mythical Man-Month. The corollary of
Brooks's Law is that there is an incremental person who, when added to a
project, makes it take more, not less time. Brooks adds that "Nine women
can't make a baby in one month".
The simple explanation
for the situation is that new people, though experienced, need training of
various factors of the system: not only the technical factor, but the
functional, social context of the system. Furthermore, adding more people to an
existing project creating a larger communication network, with the number of
possible interactions between people in the development team increased
significantly.
However, as surprising as it might have been,
the project succeeded. I think the reason here is the willingness of the newly
added experienced developers which might have been the result of the
encouragement and remuneration of the company. It was indeed the matters of
trust, management and reward.
Reference
No comments:
Post a Comment