CSCI 5828

Ken,

A couple of comments on Thursday's class.

Regarding estimations, besides programmer optimism, there are some other factors which come into play about estimate accuracy. Keeping in mind that an estimate is a - hopefully educated - guess, then the accuracy of an estimate is determined by knowledge of the domain to be solved and of the team to solve the problem. Therein lies some of the problem.

If we look at developer turnover, recent surveys have indicated that a developer or software engineer will change jobs as frequently a 9 months to a year. Many aspects influence turnover, such as better pay, better opportunities, more interesting work, projects becoming a death march, and others too numerous to list. Some of that turnover exists as transition within an organization, others transition out. As a result, knowledge of a projects's domain must be developed at the same time as new employees are brought up to speed, while often developing, concurrently, the requirements and estimates. So, an engineer may be estimating based on the known skillset of a prior team, while the new team is an essential unknown. Documentation of prior related projects helps only insofar as there are similar capabilities between successive teams. However, no amount of documentation will completely capture the domain knowledge or the "tribal" knowledge of a development team.

Add into the mix a propensity for companies to hire contractors to come in for the length of the developent phase. Again, the software engineer or project manager is faced with transfer of knowledge and an unknown team. If there is also an in-house development group, members of the in-house team may not be used on the development aspect of a project, resulting in additional ramp up time, assuming that there is a smooth transition. In both cases, post development transition may very well be poorly managed, with development team members leaving a project prior to the transition.

Personally, there is often another twist, one that speaks of an problem with understanding. How often have we seen a scenario where a management team says: We've promised a complete product by this date, so get to work. As often as not, there are business problems to be dealt with if the date or functionality is missed, and management can be deaf when it comes to reason under these circumstances.

Given the state of many development processes, there is often the concept among managers of what I call "hot pluggable programmers." By that, I mean that if we need a person in an area, take him or her out of what they are doing and drop them into the latest hot spot. This really is an example of two problems that Brooks addresses, one being that adding new people to a problem area only prolongs the problem. The other is the assumption that all developers and engineers have the same ability to make contributions. As Brooks points out, there can be as much as a 26 fold difference between engineers. Add into that mix that many domains have increasing technical complexity, and it makes for further slowdown on a project.

Another area I wanted to comment on is giving the users of a system visibility into the engineering process. That works only as far as those cases where a management team will allow their people to participate in a project, and only where the user's participation is limited to those areas where participation is appropriate. In some projects, a management team will not allow their employees, or the right employees, to participate in the project when gathering requirements and making reviews. As often as not, the software process is seen as long, involved and expensive, or the domain expert may be perceived as beeing needed elsewhere more urgently than doing just another software project. In addition, many will wish to be involved with design decisions, where it may not be appropriate to participate. So, careful management and inclusion of the correct users is another aspect of the engineer's or project manager's role.

Last, I wanted to address the communication problem by saying that the n(n-1)/2 rule is itself optimistic. It assumes that all participants have the same communication skills and knowledge base to draw on. Experience shows that is not the case. Add in the translation process when communicating outside of the project team, which all engineering teams must do, and it becomes clear that an additional, independent weight must be given to each leg in the graph. Essentially, take the n(n-1)/2 a much more expensive formula. That's the good news. :-) The bad news is, the weight can change, depending on the situation...

-Bob