The Code Whisperer

Practical, on the ground advice for efficient software development

Archive for April, 2008


36 Common Software Development Mistakes
2. Weak Personnel

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.

36 Common Software Development Mistakes
1. Undermined Motivation

It’s not just software development that suffers from this morale crushing side effect. Sometimes it’s not a consciously bad decision, but events such as a senior manager taking holiday at a crucial part of a project do adversely effect the moral of a team. I’ve seen some shocking examples of this:

  • An overheard conversation between two senior manager: “We’ll terminate one contract a week until morale improves” (this moral boosting tactic started and lead to the majority of contractors in the development team not renewing their contract)
  • Being assured that a large insurance company was OK financially, despite a poor underwriting technique that didn’t look at the sudden rise in claims, to then find in the Sunday newspapers that the firm was technically insolvent

Whether it’s intentional, accidental or incompetence, reducing the moral of a development team will slow progress and possibly create such a bad atmosphere that it can never be recovered from without significant change of leadership.

So what motivates people? It’s not money, although this plays an important part, it’s:

  • Respect - self respect and the respect of their peers and management
  • Making a difference - having an influence in the progress of the company and more fundamentally being listened to
  • Challenge - developers like the challenge of a new development environment (e.g. .NET from C++ and VB6) so it’s important that there is a roadmap for software development that provides this challenge
  • Advancement - this won’t apply to everyone, so developers want to stay as developers and have no interest in management, but in both cases there needs to be a recognisable career path
  • Money - if your team makes the company do well, shouldn’t they be rewarded?
  • Security - most people need to know the next month’s pay cheque is safe. The events at the insurance company I mention above causes a long queue at the fax machine on Monday morning. Having been lied to and not knowing how secure their job was caused most people to abandon work and look for another job
  • Work environment - we’ll cover this in a later classic mistake, but suffice to say smart calm environments are productive. Dirty and noisy environment aren’t

Style of leadership makes all the difference to morale:

  • Understand individual team members - knowing what motivates different team members is vital in having a productive team, make sure you cater for all the team’s needs
  • Celebrate success and learn from failure - I talked about this a lot on this blog, so, so important
  • Give praise - organisations where senior management only appear when there’s a problem will never have fully motivated staff. A long lunch after a successful software launch does so much to strengthen relationships and build morale
  • Be visible - during good times and bad, but be aware that your reactions and expressions in public have a direct effect
  • Stay positive - leaving a successful meeting with a glum face can send all the wrong messages, an a positive view in a storm gives hope to your team, but never manipulate this to give a false impression
  • Generate enthusiasm - enthusiastic teams are generally productive and resourceful, they will try to find better ways of doing things and much more likely to produce better quality work
  • Lead from the front - in good times and bad show that you have control
  • Set goals and achieve them - this is so important for the advancement and challenge aspects of your team’s motivation. Don’t pay lip service to goals, they are a powerful tool, make sure they are well known in your team and company and that you frequently measure progress towards them and make decisions that assist in their realisation

36 Common Software Development Mistakes

I’m a big fan of Steve McConnell’s Rapid Development book. Although the title suggests that it covers a new trendy method of software development, in reality it provides plenty of tips and suggestions for any method of development. In the book Steve lists 36 classic mistakes made during software development that will adversely affect the delivery of the project. Often these mistakes are made in an attempt to reduce timescale or bring back the delivery date, but they make matters worse.

I’ve picked from Steve’s list and my own to produce the 36 Common Software Development Mistakes:

People

  1. Undermined motivation
  2. Weak personnel
  3. Uncontrolled problem employees
  4. Heroics
  5. Adding people to a project
  6. Poor office environment
  7. Relationship between developers and “customers”
  8. Unrealistic expectations
  9. Lack of project sponsorship and buy in
  10. Lack of user input
  11. Politics over substance
  12. Wishful thinking and blind optimism

Process

  1. Over optimistic schedules
  2. Insufficient risk management
  3. Third-party failure
  4. Planning failures
  5. Wasted time during the “fuzzy” front end
  6. Skipped or inadequate requirements and design
  7. Inadequate testing
  8. Insufficient management controls
  9. Missing tasks from estimates
  10. Catch-up later
  11. Code like hell programming
  12. Insufficient coding standards and development process documentation
  13. Insufficient code reviews
  14. No defect tracking tool

Product

  1. Requirements gold-plating
  2. Feature creep
  3. Developer gold-plating
  4. Push-me, pull-me negotiation
  5. Bleeding edge development

Technology

  1. Silver-bullet syndrome
  2. Overanticipated savings from new tools
  3. Switching tool mid project
  4. Lack of source control
  5. Lack of automated build process and tool

Over the coming weeks I’ll be looking at each of these in detail.

Rules of the Garage

  Bill Hewlett and Dave Packard's garage at 367 Addison Ave, Palo Alto

Bill Hewlett and Dave Packard’s garage at 367 Addison Ave, Palo Alto

In 1938 from a garage in Palo Alto, Bill Hewlett and Dave Packard produced their first product, an audio oscillator. By 1940 Hewlett-Packard have outgrown the garage, rented a building and are on there way to becoming one of the world’s largest IT companies. The concept of “the garage” has remained a focal point within HP, and the actual property and garage Bill and Dave started from is now owned by HP and is a state historic landmark.

In 2001 I was working with an internal development team at Hewlett-Packard in the UK, when they reaffirmed the garage concept. Placing a mock garage on the front of the building really hammered home the message. HP also came up with what they called “Rules of the Garage”, which I believe should be applied to most, if not all teams and organisations. Here they are:

Rules of the Garage

  • Believe you can change the world.
  • Work quickly, keep the tools unlocked, work whenever.
  • Know when to work alone and when to work together.
  • Share tools, ideas. Trust your colleagues.
  • No Politics. No bureaucracy. (These are ridiculous in a garage).
  • The customer defines a job well done.
  • Radical ideas are not bad ideas.
  • Invent different ways of working.
  • Make a contribution every day.
  • If it doesn’t contribute, it doesn’t leave the garage.
  • Believe that together we can do anything.
  • Invent.
    • Learn from failure.
  • I would like to add one of my own

Writing a Procedures Manual

A few years ago, and much to my wife’s horror, I took a book called The E-Myth Revisited by Michael E. Gerber with me as holiday reading. In this book E stands for Entrepreneur rather than Electronic, and through examples it demonstrates the value in having business processes documented. The idea is that as the fledgling company grows, you can employ staff who are smart and can get things done, point them at the procedures manual and they should be able to get on with the job with a minimum of time consuming supervision, something the growing business doesn’t have a lot of. This frees the business owner from doing jobs in the business he or she shouldn’t be doing and lets them get on with working on the business. Part of the reason that some of the fast food franchises are just about identical the world over is because each franchisee has an operation manual explaining exactly how to run the business. It is one of the best business books I’ve read.

Unwittingly I’ve been producing procedure manuals in various forms for years. When I was rallying we had a ring binder with laminated instruction sheets for various jobs on the car. If we needed to swap parts or make adjustments during service time we had detailed instructions on how to do it, so that the work was completed in the shortest possible time.

A Paul Gorman seminar I went to in 2006 had a guest speaker from a company that hired broadcast quality video camera equipment from their office in London to world locations. Kits were tailored to the needs of the individual hire and sometimes, generally due pressure of time, essential bits of the kit were left out. Fed up with checking each kit personally, the managing director instigated complete documentation of the company’s processes and added checks at various stages of despatch to at least reduce the number of mistakes being made. Once this had been completed ownership of the process documentation passed to the individuals involved in that part of the company. If they could improve the process they did, and documented it. The quality perceived by their customers soared - the equipment was identical, simply the correct equipment was being delivered. The company ran smoothly and when a kit sent out failed, a task normally handled by the managing director who was away, the staff member simply located the process documentation, followed it and the crisis was over by the time the managing director appeared in the office.

I highly recommend reading Michael Gerber’s book, even for large companies. It was a real eye-opener for me and now we document every process Operations Support does. Our documentation is simple and effective, a well indexed word processing document with plenty of screen shots and photographs.

If you decide to create a procedures manual, I have a few pointers:

  • The aim of documenting the procedure is so that pretty much anyone could pick up the document and complete the process, so write accordingly. Consider a glossary if jargon or abbreviations are commonplace
  • If possible have someone who isn’t familiar with the process try out the documentation - you’ll soon find out if there are any bits that need further explanation
  • As in out video camera example above, the point of the documentation is that it’s followed. There really is not point having it if it’s not used on a day-to-day basis. Consider having check lists to help verify that the process has been carried out
  • Make sure the procedures are available to all the staff members that need them. Obviously you need to be careful with some areas of the company, for example accounts. Print copies of the procedures and keep them up to date, so that you are not reliant on the computer being available. Laminating is a good idea if there is a chance that the sheets could get mucky, as I did with the rally car book
  • Involve your development team in the documenting process. Make sure they understand they are part of the process and they have a say in it. All you are doing is making it easier to get things done, there’s no performance measurement involved

MeWare

There’s an interesting posting on Eric Sink’s blog called Yours, Mine and Ours. It places software into one of four categories:

  • MeWare: The developer creates software. The developer uses it. Nobody else does.
  • ThemWare: The developer creates software. Other people use it. The developer does not.
  • UsWare: The developer creates software. Other people use it. The developer uses it too.
  • NobodyWare: The developer creates software. Nobody uses it.

You’ve probably used, seen or heard about software in each of these categories.

I’ve taken over producing the racing results at the sailing club I’m a member of. The chap that does it has been doing it for a long while and has developed an application to help. Most of the hard work in turning the hand written sheets produced by the race officer into 1st, 2nd, etc for the individual race is taken care of by a spreadsheet application at the club house. I get a printed sheet from the spreadsheet, plus the original sheets and sign on sheet. I then use the results application to collate the individual race result into results for the various series that go on through the summer. The application produces HTML and text files for the website and club magazine.

The results application is meware. Written in C over the last ten years at least it’s written to do one thing and one thing only. No mouse control, text interface and littered with keyboard commands. The first time you use the application it is a nightmare. It’s not intuitive, finding functions isn’t straightforward and there’s the nagging doubt that the data hasn’t been saved. However, after a few weeks of struggling, the beauty of the application becomes apparent.

  • It’s small (424Kb) and very fast
  • There’s no unnecessary features, everything in it is used
  • No major features are missing
  • It matches the way the sailing club runs its race series perfectly
  • Entering via the keyboard is quick, selecting via the mouse does slow the process down
  • There’s a very good help document

I’ve been interested and involved in motorsport for many, many years and I’ve often surprised when looking at a race or rally car in detail how good it looks from a distance and how “odd” it looks close up. When I started rallying myself I found out why. The car is simply built around the driver (and co-driver for rally cars). The gearstick is bent at the right angle, the pedals are moved and the seat bolted to the floor. Anything that isn’t needed is removed. Trim panels are discarded and the wiring loom is left on show. It’s fast and it’s perfect for the driver. Just like meware.

Would I change the results application? Of course, notably I would like to be able to generate HTML files for every race series set up not one at a time, but this would probably save only one minute a week (although it should be said that saving time isn’t everything, preventing a mistake is a strong driver too). Significantly the club is trying to manage better the flow of information from the membership database to berthing and racing, which will necessitate a change and, I suspect, a new application that more people can use straight away.

I’m not suggesting that we only develop software with a meware mindset, that clearly wouldn’t work for applications that cover a broad range of users, but there are some pointers here for niche applications:

  • A lean application is a fast application to use
  • Extra features take time to write and test and may have little use or not save the user much time. However also look at whether the feature will prevent a mistake being made
  • Match the application to the manual process before or after. For example if the user enters data from a form, make sure the order of the data is the same as that on the form
  • User interface controls such as list boxes and check boxes can get in the way of productivity. Make sure keyboard control is always an option
  • Provide good quality help information, whether built in or a simple document

Skills for Maintenance Programming

Given the choice of developing new code or correcting/enhancing existing code, most developers will opt for developing new code. It allows them to do it their way without fighting through a number of different programming styles and convoluted logic to fix problems introduced by someone else. An enhancement of any great substance often results in calls for a re-write. It’s no surprise that maintenance is seen as “B” team work.

I’ve worked at a number of installations where the new recruits work on maintenance to “learn the system”. I think this is wrong. Someone once compared software maintenance to surgery in that cutting a body or software open leaves a scar. In the same way that in an operating theatre you would want the experienced surgeon who will make the smallest possible incision, with your software application you don’t want a developer who is going to check out half of the source code and make changes all over the place. You’ll end up with more checked out code and changes that you need or want. Please note I’m not suggesting that surgery and development are on a par in any other way.

I firmly believe that software maintenance needs developers with a specific mindset, which, quite likely, will be the best developers in your team. Here’s a few qualities you should look for:

  • Doesn’t shout “re-write” within 10 minutes of looking at any problem. There are times where a rewrite may be required, but generally it’s easier to re-write than understand the existing code, hence the cry, but losing years of testing and bug fixing in the process
  • Can work without documentation. Regrettably many computer systems have poor, non-existent or out of date documentation, which makes maintenance a nightmare. The maintenance programmer in these cases must be able to understand what is going on from the code and debugging sessions
  • Understands that sometimes the seemingly rubbish bit of code in front of him or her may have been done that way for a good reason and doesn’t dismiss it out of hand. If this was the case I would hope there were comments to support the decision made, but this isn’t always the case
  • Knows that in a complex system making a change can have a knock on effect elsewhere and investigates fully before making the change. Recently I saw the effect of not appreciating this, and not testing fully - it wasn’t pretty
  • Fully tests all changes, even a one line change. This goes hand in hand with the previous quality - testing the implications of the change made
  • Good problem solver and doesn’t give up easily
  • Prepared to implement a good quality fix or enhancement, not a quick bodge

I’m going to end this post with a quick note about enhancements to existing code. Sometimes code isn’t designed with extensibility in mind, which makes adding new features tricky. When this happens you need your best developers in charge of the technical design. It’s important that the designer can look at several different ways of implementing a change and select the one that works best with the existing architecture and is the least intrusive, and not simply the first one thought up.

Death of the Computer Manual

Back in my mainframe days of the early 1980s’ I worked on a COBOL controlled circulation system for trade magazines. The software house that wrote the system and provided a bureau service was fun to work for, demanding and I gained a lot of knowledge about software development in a short space of time. The way software houses work doesn’t suit every developer, but if you’re smart, prepared to work hard and have a get the job done mindset you’ll enjoy the experience.

There was a chap there called John. He had been there pretty much since the company was founded, had a brain the size of a planet, a pretty gruff nature but was prepared to help anyone, provided they put some effort in themselves. Asking “what’s the command to do x” would instantly invoke a “read the manual” response. A more considered question, for example “I’ve looked at this and I can’t decide the best way to do it” would release years of wisdom.

The most important thing I learnt from John, was simply if you needed to look something up, read all you can. Now this didn’t mean if you needed to remind yourself of the syntax of a command you didn’t know, but if you had no idea of its existence. This approach gives you a very broad grounding in a subject, beyond a simple need to know basis.

I’m not sure when the computer manual disappeared. They were replaced by a variety of books on how to do things and third party reference books, and these, it seems, has been replaced by the Internet.

I was listening to Joel Spolsky and Jeff Atwood’s first podcast from their new www.stackoverflow.com developer’s website. In it they talk about the demise of the computer book as most questions are asked online and then talk about why this doesn’t always work. In simple terms if someone discovers a problem with software (be it an application, IDE or language) there may not be a solutions, so a posting to a forum could result in a number of “you can’t fix it” replies. The software vendor then, some time later, releases an upgrade, but other people searching for the same problem are likely to see the “you can’t fix it” messages first and unless they dig further may not find the answer they need.

The web’s great for finding resolutions to problems. If it’s a bit of code that can be easily and completely tested go ahead and use it. If it’s opinion or can’t be tested now, as in the scenario above or, for example, a new way of building software or a new architecture don’t adopt it without clarification.

The Golden Rule of Internet Research

Don’t base a decision on one person’s opinion or comment. Clarify everything. Just because it’s written doesn’t make it correct

The last part can also applies to books. I’ve seen mistakes in books, but this is rare. The amount of effort and money required in putting a book on the shelf tends to discourage people who will happily share their opinion on the Internet. I include this blog in this category. Just because I’ve written it doesn’t make it right for you and your development.

I would encourage you to allow your development team time to expand their knowledge by digging a bit deeper in the same way John did. Expanding their knowledge is good for them, good for the team and good for your development. Encourage people to be more self sufficient rather than interrupt their colleagues, maintain a library of books and articles, get a Wiki online for information specific to your development, industry and company.

Team Management “The Apprentice” Style

I’ve watched bits of each of the UK series of The Apprentice, I know it’s a TV show yet I still get quite irritated by the twisting back-stabbing nature of some of the people on it. It’s a game show not a job interview, but I can’t quite fully accept it. I wonder when people in the boardroom are complaining about the project manager whether they consider the points they make when they are leading.

Watching some of the tasks I can only feel sorry for the project managers:

  • Team members wanting to take control to undermine the PM and get him or her fired
  • Team members not working at 100%, but still looking busy so the team fails and the PM gets fired
  • Incorrect decisions not rectified
  • PM trying to do a key role and not just manage

The first two problems can be found in any team and frankly leadership skills are the only way to resolve it. However it amazes me that some of the contestants just don’t understand how important it is as a team member to take direction from the manager. It’s important to voice your opinions or experience, but if direction is taken then follow it.

We learn more from failure than from success, but this is not the way society is geared. I’m not condoning malicious errors or incompetence, but as I’ve said before in this blog, genuine mistakes do help form a team or product. Sticking to a decision for fear of admitting a mistake is simply foolish, but we see it every day in business, politics and education.

This last point is slightly complex and becomes harder as the weeks go by and the team decreases in size.

In last night’s episode, project manager Simon Smith was fired having lost money at a photography shoot in the Bluewater shopping centre. Clearly Simon had a flare for photography as echoed by professional photographer Terry O’Neill in the follow up programme. If he was the best person to take photographs, I really don’t think he should have been project manager, simply because there were enough team members to have a dedicated project manager, who would have seen the problems with printing and had it sorted much quicker.

A strong message from small business marketing experts such as Paul Gorman is that you should work on your business not in your business. What that means is working to market, expand and promote your product or service, and not spend time bookkeeping or ordering paper clips. This isn’t always possible and the smaller the company the harder it becomes. The same applies to development teams. In a large company, those that manage should only manage and not write code, test applications, etc. As the size of the company decreases so does the ability to pull managers away from the “coal face”. But look at it this way. Should a manager on, say £45 an hour, be carrying out tasks that an office admin position pays £10 an hour? No!

When Things Go Wrong and Office Space

I’ve just got back from a skiing holiday in Les Houches, near Chamonix in France. We were there last year too and it’s a great, quiet resort for families. If you ever go there check out Le Creposaure opposite the Bellevue lift - very friendly, excellent food and good value for money.

Les Houches, France. Peaceful, beautiful skiing

Les Houches, France. Peaceful, beautiful skiing

The weather was generally good, but we had one afternoon where the cloud came down and left us with a visibility of 15 metres or so. We were quite close to the cable car so took the opportunity for the children to experience skiing in these conditions and also teach them about what to do, i.e. keep sight of the person in front, shout if you lose sight of them or fall. I’ve done a bit of mountain walking so know the basics on keeping safe and share the despair of the mountain rescue teams when they have to risk their own necks to find ill-prepared groups of people who think they are on a Sunday afternoon stroll only to find the weather changes and they need a map to find their car. As nice as the picture is, skiing takes place on a mountain and the same rules apply - weather can and does change very quickly.

Just as we were about to go we discovered a very distraught lady who had become separated from her husband and friend. She had fallen and then couldn’t locate the other two, didn’t know quite where she was or where to get back down. They had one phone and one piste map between then, neither of which was in her possession, although the phone wouldn’t be much use in this situation. I can only imagine the panic her husband was feeling.

So what has this to do with software development? Things go wrong on a mountain as well as in software development. With most outdoor activities there is planning for things going wrong - a life jacket on a dinghy, first aid kit in a walkers rucksack. Participants in these activities often spend a fair bit of time and money organising for unexpected events or mistakes. But we don’t always do this with software development. So today’s blog entry is to plan for things going wrong. Put processes in place that the whole team are aware of to allow quick recovery from the problem, even if it’s “if this happens contact this person on this number”. As you come up against new problems use the Five Whys to get to the root of the problem and address that. And if you go skiing in a group make sure everyone has a mobile phone on them, charged up and turned on. All you need is an old phone with a pay as you go SIM card in it, but double check that it will work abroad.

The bad weather gave me time to watch some old films I haven’t seen in a while, one of which was Office Space. There is an IT connection and for anyone who has worked in a cubicle it rings very true. It also serves as an example on how not to manage, and certainly how not to lead. I cringe every time the cup carrying boss appears at a cubicle and asks “What’s happening?” and, without pause, delivers some form of instruction or comment. Pure horror!