Don’t Repeat Yourself, but especially Don’t Repeat Yourselves.
An interesting case on duplication was made: while it can be avoided with practice in personal projects, in collaborative projects, “interdeveloper duplication” can creep in.
While it’s easier to talk about in comparison to managing across a team, a worryingly inefficient case study was provided:
“Perhaps the hardest type of duplication to detect and handle occurs between different developers on a project. Entire sets of functionality may be inadvertently duplicated, and that duplication could go undetected for years, leading to maintenance problems. We heard firsthand of a U.S. state whose governmental computer systems were surveyed for Y2K compliance. The audit turned up more than 10,000 programs that each contained a different version of Social Security Number validation code.
At a high level, deal with the problem by building a strong, tight-knit team with good communications. However, at the module level, the problem is more insidious.”
The book mentioned a pragmatic solution: encourage communication between the developers. From this, the importance of daily standup meetings to discuss the current “library of knowledge” cannot be underestimated.
That concludes day 8. See you tomorrow!
#PathToSWE
