The Code Whisperer

These are two distinct areas, but can be interlinked, which is why I’m covering it in one go.

Project sponsors are more often seen in large organisations where software is written for internal purposes. They tend to be senior management and add practical help and credence to a project. They also need to have a passion about the project and willing to drive it through any obstacles the team come across. I am assuming that the project is a worthwhile exercise for the organisation, another benefit the project sponsor will require - a view from outside the immediate project team.

With small software houses the project sponsor, in my experience, doesn’t exist. The development team aren’t trying to implement new processes or functionality into part of their organisation and it’s up to the sales team to present the application to other companies. In The Beermat Entrepreneur the authors Mike Southon and Chris West talk about the benefits of a sponsor for the fledgling company. Typically the sponsor would be well know in the industry and provide similar guidance to an internal project sponsor in a large organisation.

Too often we have a battle between users and the development teams, which covers the buy in part of this posting. I consider buy in necessary for the business the application is supporting and the team that are developing it. Buy in is a general belief in the aims of the project and not necessarily agreement on every requirement and technical solution. Tracey Kidder’s The Soul of a New Machine follows Data General building a new 32 bit mini computer in the late 1970s. It is one of my favourite books and one I haven’t read for a while. Early on after the team has being recruited the project managers, including Tom West (no relation) “sign-up” the team for the development. Basically this means giving all of their waking hours to the project, but it’s similar to buy in for a less pressurised project. The Soul of a New Machine highlights certain project techniques and effects I would avoid at all costs, heroics being one, but the book shows a good example of a “can do” team.

In one case I witnessed many years ago, a mainframe based contact management application was developed very quickly, with limited information to support a major change in part of the business. The application wasn’t perfect by a long shot, but did offer basic functionality and was stable. However there wasn’t a project sponsor and the business viewed the system as worthless, taking every opportunity to criticise the application and the team that had written it. I found out later that the people complaining the most were sales people brought in who weren’t performing and using this as a diversion. I don’t know what became of the application, but I know the turnover in the team was very high, including project managers, which is never a good sign.

It’s hard to predict the outcome of this example if either a project sponsor or there had been buy in from the business users, but I would expect either one factor to have made a significant improvement to at least the perceived success of the project. The negative reactions from the business were the opinions of two overbearing personalities, which set expectations for the other users. This common human trait can be played to the projects advantage with a sponsor. I’m not suggesting that they overstate the project like a spin doctor might, but positive promotion of an application will foster a more positive reaction.

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.