The Code Whisperer

Practical, on the ground advice for efficient software development

Archive for May, 2008

Next Entries →

36 Common Software Development Mistakes
6. Poor Office Environment

Published May 8th, 2008 in Development, People | No Comments »

Software development at most stages is thought intensive. Generally people take around 15 minutes to get into the flow of what needs to be done, and then can remain in that state for several hours. However in crowded and noisy open plan offices the average interruption is estimated to be every 11 minutes. It’s hard to see how anything gets done, which is why often there is a band of early morning workers and a band of late night workers, achieving productivity when the office is quiet.

In the first 10 years of my IT career I only had an ideal environment to work in once, in my first job as a trainee COBOL programmer. I had an office to myself, could shut the door, plenty of desk and storage space, a window to let in natural light and could switch off the phone. No email back in 1981, so interruptions could be easily minimised. Since then it’s been either a shared office or large open plan offices, neither of which are conducive to thought driven work.

I’m not going to go into detail about the ideal working environment for development staff, in which I include analysts and QA/testers, as there is plenty of information in books and on the Internet, but I do have a few ideas and grumbles picked up over the years.

  • Some organisations have an open door policy. I understand the reasons behind this idea, but it should be completely unnecessary if the members of that organisation have respect for one another. I’m not advocating office doors should be shut all of the time, but there are periods where the door needs to be shut to indicate a period of intense thought and fend off unimportant interruptions
  • Email is a blessing and a curse. It’s great as a way of dealing with messages when you want, but few people work this way, responding to email instantly and using up huge amounts of time in the process - remember every time you stop what you are doing to read an email it takes 15 minutes to get back in the flow. I highly recommend looking and responding to email only two or three set times a day and shut down your email client for the remainder of the day. Make sure you have an effective spam filter for all incoming email. There are plenty of services to choose from, with a variety of prices, plus you can route domain email via Google Mail and strip our spam for free
  • I’ve never been a fan of instant messaging, maybe it’s an age thing, but I find the constant interruptions frankly irritating. However I can see it has a use for conferencing, but I much prefer the telephone and there are a number of companies that offer conferencing at just the cost of the telephone call, with no additional equipment required
  • Some years ago a UK supermarket with an open plan office gave staff a red hat that they wore to signal that the did not wish to be interrupted. If I remember correctly there were time limits on wearing the hat, which I think defeats the object to a degree. I appreciate having a maximum time per week stops people from constantly appearing uninterruptible, but having the hat on did make you look silly so would discourage some people from wearing it constantly
  • Storage space is a constant problem in offices. We’ve recently invested in quite cheap cupboards from Ikea that utilise the otherwise wasted wall space in our small office. This has made a huge difference - we can find things quickly and the work surfaces are free from clutter. Clear desk policies make a lot of sense, but make sure that the pile of papers is being stored properly not just hidden in a cupboard
  • I’m 6 foot 4 and find most desks too low. A low desk means I also have my chair low and my legs end up being wrapped around the base or stretched out in front causing all sorts of aches and pains. I custom built the desk in my office, which sounds fancy but really isn’t, being simply made from varnished MDF, legs from Ikea and a number of blocks to get the height of the desk right in relation to the chair at the right height. If people work effectively for long periods at a time at a desk they must be comfortable, so the height of the desk needs to be adjustable, even by placing props under the desk legs. Poorly adjusted desks and chairs can cause back pain, which means time off work, which leads to delayed projects

36 Common Software Development Mistakes
5. Adding People to a Late Project

Published May 7th, 2008 in Development, People | 2 Comments »

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

36 Common Software Development Mistakes
4. Heroics Part 2

Published May 6th, 2008 in Development, People | No Comments »

Following on from the previous posting, heroics aren’t unique to the computer industry. Before we had children my wife was the production manager for a holiday company responsible for their holiday brochures. These were delivered to the travel agents in the autumn just after most people had returned from holiday.

Broadly speaking her team’s role was to collect copy from the various marketing departments, add library photographs and lay out the pages. The pages would then be approved by the department responsible for that area of the world and would then go on to print.

Every year it was the same. Copy was late, and many changes would be made once the page had been initially laid out. The reason for this was simple. The brochures were always delivered on time and the team worked as much as necessary, late every night and most weekends. Every year. This is wrong, wrong, wrong. As this culture was ingrained in the organisation long before Mrs West took over, the marketing departments took it as their right to ignore deadline and deliver poor quality copy late. To change this would require direction from management above all of the departments, which in this case was sadly lacking.

A friend contacted me regarding the last Heroics post and we discussed another detrimental aspect of heroics - the monetary cost. Both he and I have worked in organisations where planning has effectively been thrown out of the window and there is a huge coding mountain to climb. Paid overtime is unlimited and unchecked, which allows people to regularly clock up high number of hours, which will add to your costs if it’s paid overtime. Overtime is fine for short periods and useful to bring a schedule back on track, but if overtime goes on for too long (and this really depends on the individual), tiredness creeps in so productivity and quality of work reduces.

So in periods of intense or extended overtime make sure you are getting sufficient productivity (look at it as a return on investment, if a team member is working 10 hours a day instead of 7.5 and producing 8.5 hours of work, 1.5 hours is being wasted), whether overtime is paid for or not and if productivity has fallen, stop or reduce the overtime until energy levels return to normal and overtime can be effective again, or you have replanned.

36 Common Software Development Mistakes
4. Heroics

Published May 2nd, 2008 in Development, People | 1 Comment »

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.

36 Common Software Development Mistakes
3. Uncontrolled Problem Employees

Published May 1st, 2008 in Development, People | No Comments »

I’ve seen a close team ripped apart by an individual who seemed to enjoy rubbing people up the wrong way and misreporting events to senior management in such a way that it appeared the rest of the team had verbally attacked him. Additionally in this case, the little work that was being produced was of poor quality. If the situation had been left any longer team members would have started leaving.

This is an extreme case, and thankfully not all are as intentionaly destructive. Arguably the most important factor is that team members must get on. If there’s friction in their relationships work will suffer. It’s not just verbal communication, however. With development, poor coding and/or design, reluctance to follow coding standards or the team’s procedures should ring alarm bells. In an ideal world, design and code reviews will highlight these issues, but if these aren’t taking place problems can be discovererd very late in the development process.

Problem employees must be removed, whether to a different team or company and before any serious damage is done to the remainder of the team. Be careful, however, that a legacy of poor work isn’t being left for someone else to correct.

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.

Next Entries »