The Code Whisperer

One of the most blatant examples of unrealistic expectations I have experienced was at a motor manufacturer whose UK subsidiary was rewriting their dealer system. The system controlled just about every part of their business from sales, through parts and servicing to accounting. The then current system was DOS based and although worked fine was looking dated and reaching the end of its usable life. The replacement was a n-tier, VB5, MTS (now COM+) system with Oracle as the database. The specification was the old system, a pile of enhancements and knowledge held in 3 dealer consultants heads. Already this isn’t looking good. Then the bombshell, planning. The conversation went along these lines:

“The accounts system will take 3 months to complete”
“How have you calculated that, these plans aren’t detailed enough to work out how much time is required”
“Accounts represents 25% of the complexity of the old system, and we want the new dealer system developed in a year, hence 3 months”
“And how many developers?”
“3″

So that’s 3 man months to:

• Understand the old system
• Find and understand the enhancements
• Pick up further changes from the dealer consultants
• Technical design
• Approval for GUI
• Development using technologies that then were very new
• Unit and system test
• Integrate with the main shell and with other parts of the system, e.g. sales

Clearly this was unrealistic expectations on a grand scale, but it took 9 months to realise that this was the case.

Unrealistic expectations is not restricted to only planning and timescales. Over the years I’ve seen a number of other cases:

• Sales made on the back of features that don’t exist in the application, then a scramble to implement them
• Inappropriate software selected and expected to be configured or changed to fit business practises
• Old, slower development environments, but development speeds of newer development environments
• Development and/or implementation using old, slow, small hardware

In my experience people working with projects that have unrealistic expectations tend to have one of two mindsets: 1. Heroics - let’s get it done and 2. We’re not going to make it so do what you can, but only 9 to 5.

Neither of these mindsets is good for the project. Heroics we have discussed, but there is the other side of the coin in which everything is viewed negatively. Getting either of these entrenched in a project is deadly, which is why effective planning and being in control of the expectations is vital. Going back to my example, the project manager should never have agreed to initial timescales as they were clearly too short. The particular project had 3 different project manager over 2.5 years before the project was cancelled, to be replaced by a third party application.

There are a couple of things left out of yesterday’s post I wanted to follow up on today.

The most productive environment for thought based work is adequately sized, quiet, individual offices. However there is a negative aspect to this, the reduction in the feeling of being part of a team. With open plan offices and, to an extent, the cubical layout, teams tend to be clumped together, which gives them a sense of group identity. The identical nature of open plan working spaces means that it is relatively easy to move people around as projects finish and a new team is assembled for a new project.

With individual offices comes ownership and personality. The incumbent of a new office will move things around to their liking and have personal items such as photographs and the ubiquitous pot plant that identifies the workspace as their own. This is good and should be encouraged as the more comfortable the team member is the more productive they will be and likely to stay with the company longer.

If teams change, moving individual offices is not straightforward and you could end up with a team spread over several floors or even buildings. From a team bonding angle this isn’t ideal. In my opinion team bonding isn’t the project being worked on or the company, it’s the personal interaction between the team members, formed by agreement and disagreement on subjects aside from the project and office. It may be an Apple v Windows discussion, last night’s football results or who should be evicted from the Bug Brother house next Friday. It’s trivia, it doesn’t really matter but it bonds people together, or not, but then you have a more serious problem that would need addressing in any case.

With individual offices you lose the team bonding that happens by virtual of being in the same working space, so it’s important that it is recreated in other ways. I worked at IBM’s Hursley locations for a while in 1993. The office environment there was mostly small offices, but contained more than one person and some had almost no natural light so can’t be considered ideal. To overcome the segregation the team generally had lunch together and morning and afternoon tea and coffee breaks at set times, something I haven’t seen since. Now 30 minutes coffee drinking time a day may seem unproductive, but this wasn’t the case at IBM and if you add up the time taken with ad-hoc coffee grabbing and having to spend time getting back the train of thought, 30 minutes a day is a bargain.

So if individual offices are the best environment why isn’t every company doing it? It’s easy to carry out a cost benefit analysis on the additional floor space and furniture against increased productivity, but it’s deriving the amount of increased productivity that becomes the issue. Values exist in books and from studies, but until a company makes the change it won’t know whether it will be beneficial for their project and team member mix. In addition there is a “out of sight, out of mind” worry for managers. If you have passionate, motivated team members, enjoying their work they will continue to work in an individual office. The team members that use the privacy of an office to play games and surf the Internet all day will be as unproductive in an open plan office or cubicle, it’s just that it won’t be as obvious the passing management.

In his 1975 classic book The Mythical Man-Month, Fred Brooks states “adding manpower to a late software project makes it later”, which has become known as Brooks’ Law.

Generally this is correct but few rules are true without clarification and this is no exception.

The basis of Brooks’ Law is that adding people to a project increases the communication required and, assuming they have no knowledge of the development, will require training, usually by those struggling to finish the development. How long it takes before new team members are productive and how much of the existing team member’s time is taken varies massively from one project to another. Another factor is whether the remaining work can be cleanly split up or “partitionable”. I have seen panic project management where three developers are working on the same code module, inevitably slowing the whole process down.

Before rejecting the idea of adding more resource to a project, late or otherwise, consider the following:

Is the project actually late? - if the estimates and plan are wildly optimistic and unattainable, you aren’t as late in the project as your plan suggests. For example, you estimate a project to take 3 man months and have one person working on it, but in reality it will take 6 man months. After 2 man months you realise the project won’t deliver on time and reject adding another team member as there is only 1 man month left and this could add another 2 weeks to the project. However in reality you have 4 man months of work left. This is an important point because a crucial part of Brooks’ Law is adding manpower to a late project and this refers to a project that is late in terms of the amount of work and people and not by an over optimistic plan

How far into the project are you? - it’s obvious the closer to the beginning of the project you are the greater the impact of adding extra team members is. But to go back to the previous point, you must know exactly how much work remains on the project. In our example we are 2 man months into a 6 man month development. Adding more team members is unlikely to bring the project back to 3 months of elapsed time as originally estimated (1 person on a 3 man month project), but provided the work can be partitioned the delivery time can be reduced from 6 elapsed months. Let’s say that training up a new team member takes 2 weeks, although this will differ with project complexity and team member knowledge, so both team members are un productive for the 2 weeks. We’re now 2.5 elapsed months in with 4 man months of work left. Assuming the work can be split 50/50, the remaining work will be finished in 2 elapsed months, giving a total elapsed time of 4.5 months rather than 6 if we had kept only one person on the project

The project in my example is later than initially expected, by 1.5 months, but this is due to poor estimating rather than Brooks’ Law and in fact was delivered 1.5 months early by adding an additional team member at a point in the project that according to the original plan would have been classified as a late project.

An additional benefit of increasing the size of a team is that the knowledge of that project is spread amongst more people, which, depending on what happens to that project in the future, may be a valuable asset worth sacrificing a period of productivity.

By not clarifying Brooks’ Law with these 2 points and not taking the opportunity of adding resources to a project that will benefit from them, not only do you delay the project you also run the risk of inviting heroic action in an attempt to bring the delivery date back. Not revising the plan instils a culture of having deadlines that are known to be impossible to attain, but viewed as a challenge not something to be refined.

In summary:

If your project is late check the estimates and if wrong revise and re-plan. Use planning tools to model the effect of a period of unproductiveness followed by increased resource. By doing this you can make a considered decision about whether to add people or not. Before adding team members be absolutely sure that the remaining work is partitionable and that the new team member(s) will fit in well with the team.

Further reading:
www.stevemcconnell.com/ieeesoftware/eic08.htm
en.wikipedia.org/wiki/Brooks’s_law

Heroics is bringing or attempting to bring a software development in on time by working as many hours as physically possible. It is a very common activity in the IT industry and is a bad practise.

Software developments don’t always run on time and in order to deliver on time sometimes it is necessary to work a bit longer to achieve this. There is bound to happen from time to time, but when a plan expects that substantial overtime is required, the plan is flawed and needs to be reconsidered. The problem with heroic action on one project is that it’s expected on the next so that the same tight deadlines are reapplied. In some organisations heroics are even revered making tight deadlines the standard.

I’ve done the all night coding frenzy in the past. To be honest I even enjoyed it. I like to get things done so impossible scheduling appears as a challenge. But it’s not right and here’s why:

• Future deadlines are even tighter than before - if you’ve done it once you can do it again
• Working when tired can cause misjudgment and mistakes to be made
• A period of intense activity often leads to a period immediately after where little is achieved
• Planning, design, documentation, code reviews and thorough testing can easily be abandoned during this period, with a knock on effect later on in the software’s life
• Extended working periods can cause problems for people outside of work. A culture of “long hours” can have a detrimental effect on home life
• It values a “get it done no matter what” attitude over accurate planning and estimates and also the management task of moving impossible dates

There are times when the “get it done no matter what” attitude is vital, for example if a development is for a specific date. Personally I value a “can do” attitude in team members as it generates a positive vibe. To avoid heroics you need to plan with accurate estimates, monitor progress against the plan and revise the plan when required, not rely on team members to achieve the almost impossible.

This is an emotive subject and is some situations it is an event that occurs rather than a mistake. How you deal with these situations, however, can lead to the mistake.

Broadly speaking there are three scenarios:

• Problems outside of the work environment that cause the performance of the team member’s work to suffer
• Square peg in a round hole - good team member, but wrong role
• Inexperienced team members

When a team member is having problems outside of the workplace, he or she may not be aware their work is suffering. The important thing is, particularly if they are a valuable employee, to be on their side and offer as much help as possible. However, you need to wear two hats, the other one protecting the development. If it’s suffering you must make changes to protect it. You may need to temporarily relieve the team member of his work load and sometimes allowing him or her to concentrate on the problems outside work will bring these to a speedy conclusion. Don’t allow yourself to be exploited though. A friend of mine has a saying “We bend over backwards for our customers and staff, but never forwards”.

I’ve worked with enthusiastic, keen people in the past, but in a job that’s totally unsuitable for them. This creates stress for them and causes resentment in other team members. My advice is to move them to a role they are suited for within the team or company and if that’s not possible help them find a suitable position elsewhere. Again, even when dismissing someone be on their side as much as possible.

Inexperienced team members that don’t fall into the above category, and are smart and can get things done simply need training, experience and/or nurturing. Bringing inexperienced people into a team can have a detrimental effect and should only be done when the development schedule allows sufficient time for all involved. Bringing them in at the wrong time demoralises both the “trainee” and the existing team members as they won’t be able to give sufficient time generating a sense of inadequacy in the trainee and resentment or guilt on existing team members. Projects with tight deadlines you need to add only highly experienced people, who can be productive almost immediately. Training people is ultimately good for your team and company; the individual being trained will, generally, return the “favour” with extended loyalty and the existing team members involved will grow with the experience. However, it must be planned and budgeted.

I’ve assumed that there are no employment laws to follow, simply because there may be laws in one country that don’t apply in another. You must follow the appropriate procedure before terminating their employment.