The Code Whisperer

Practical, on the ground advice for efficient software development

Archive for May, 2008

← Previous Entries

36 Common Software Development Mistakes
12. Wishful Thinking and Blind/Mindless Optimism

Published May 30th, 2008 in Development, People | Comments Off

There’s an excellent bit in the BBC’s Blackadder goes Forth comedy series where Blackadder is being court marshaled for shooting the general’s pigeon and due to a mistake the hapless, but enthusiastic, George is defending him.

Blackadder: George, I’m in trouble here. I need to construct a case that’s as watertight as a mermaid’s brassiere. I’m not sure your particular brand of mindless optimism is going to contribute much to the proceedings.

George: Well, that’s a shame, sir, because I was planning on playing the mindless optimism card very strongly.

How often do we see this going on in a project?

Generally I’m a positive thinker, bordering on optimistic, but I have a natural urge to plan fully, whether it’s a software project or a weekend away, which reduces the amount of time wasted sorting things out that could have been done before.

So is optimism a bad thing? I’ve always viewed positive thinking as a good thing I feel better when in a positive mood. Somewhere there is a line between positive thinking and optimism (I’m assuming blind and mindless optimism is at the far end of the scale!), but I don’t know where it would lie. A recent blog entry by Alex Shalman titled 8 Reasons Why You Shouldn’t Always Be An Optimist. Personally I think the posting has been written from a pessimist’s view of optimistic people around them, but there is one of the eight that is familiar:

Breaking deadlines. An overly optimistic person will think it takes them way less time to complete an assignment than it really does; they do this all the time! How do you think this affects their co-workers, friends & family, and the general population?

The thing is I don’t think this is only the overly optimistic people that do this, more often than not developers underestimate the time required to carry out a piece of work, particularly if it’s a change or fix to an existing system or it’s using leading edge technology simply because so much is unknown. We then end up with too tight deadlines, which are either missed or heroics come into plan, neither of which are a good ending.

We will look at planning in a later blog, but under these circumstances we should be constantly evaluating the plan. That way we find out we are going to be later early on, allowing more resource to be added if it will help (but see Adding People to a Late Project) or plan to deliver late. I was looking at a broadband driven alarm system last night and the company made the statement about a feature that had been requested but wouldn’t be included in the next release of the software as they didn’t want to delay the release and “…wouldn’t release software that wasn’t ready just because it was due…”. Sensible words indeed.

In Code Complete Steve McConnell makes the distinction between wishful thinking and optimism. He classes wishful thinking as “It’s closing your eyes and hoping something works when you have no reasonable basis for thinking it will”. A bit like when two people are discussing an event, that could go either way and one says “I’m sure it will be OK”. How would they know this?

I agree with Steve. Wishful thinking is beyond blind optimism and has absolutely no place in the management of anything, but, regrettably I’ve seen too many examples of this over the years. If you witness either wishful thinking or blind optimism in play, question it and then do all you can to turn it into a constructive, useful plan.

36 Common Software Development Mistakes
11. Politics Over Substance

Published May 28th, 2008 in Development, People | Comments Off

The effect of office politics on any project is like the effect of kryptonite on Superman. Simply the more of it the slower the project goes until eventually the project grinds to a halt. If you saw the Sport Relief version of The Apprentice in March 2008 and witnessed Lembit Opik, Liberal Democrat MP for Montgomeryshire negotiate on behalf of his team, you’ll know exactly the point I’m trying to get across.

In my last post I talked about Geoff Polites and how he made space for people to work and protected them from things like politics that would impede their progress. This is an essential skill for successful project managers and IT directors and those that have it are rewarded with highly efficient teams. Keeping negative politics away from a development team isn’t easy, particularly in bigger organisations but failure to do so can lead to direction and time being lost in many ways.

As we’ve already discussed, having a project sponsor helps in many ways including cutting through politics, assuming the sponsor has more of a “get the job done” mindset and isn’t a political animal.

I’ve found an article called Politics-Oriented Software Development. Whilst slightly tongue in cheek, it does ring true in many places.

Geoff Polites, a Good Boss

Published May 23rd, 2008 in Development, People | No Comments »

  Geoff Polites, CEO Jaguar & Land Rover

Geoff Polites, CEO Jaguar & Land Rover. Photo from Autocar

I was reading Top Gear magazine last night and the column by editor Michael Harvey. He was talking about Geoff Polites, CEO of Jaguar and Land Rover who lost his battle with cancer in April (2008). Geoff is creditted with getting Jaguar and Land Rover back on track after Ford bought them in 1988 and 2000, and also managing the sale to Tata earlier this year. Geoff’s career is well documented and everyone who has met him has felt a passion, drive and warmth. Michael Harvey says “I can’t claim to have known Polites very well……But the few times we did meet, he always made me laugh, and I liked that”. It’s a pity, then, that the spellchecker incorrectly changed the spelling of Geoff’s surname throughout the Top Gear column.

Another comment by Michael caught my eye. He was explaining to his 8 year old son that he was upset over Geoff’s death because he considered him a “good boss”. He son asked what a good boss was and Michael explained:

“…someone who recognises the good people, then goes out of his way to create the space those people need to get their stuff done - trusting them, nurturing them, pairing them with others who will challenge them and keeping the idiots off their backs.”

Sounds like a good daily reminder for the management of just about anything.

36 Common Software Development Mistakes
10. Lack of User Input

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

Before we dive into this one, lets just remind ourselves why software exists.

To solve a “problem” or gain an advantage for the person that uses the software

And that’s it. You could argue that low level software such as drivers fall outside of this, but indirectly they solve a problem, whether it’s a USB driver for a MP3 player (advantage: listen to music whilst walking) or a printer driver (advantage: print photographs at home).

You have to involve people who will use the software in as many stages of the development as possible. This can turn out to be painful and there is a danger of bending the software to meet one person’s opinion so needs to be approached with common sense and sufficient users to form a genuine consensus. Don’t forget, however, you won’t please all of the people all of the time, so beware spend large amounts of time adding a small amount of functionality that a few people will use infrequently (unless they are prepared to pay!).

This sort of activity at the requirements gathering stage is fine, the design is fluid and if you’ve produced a prototype or wire frame then the feedback will be based on what the users see rather than what they imagine. However the later in the project this feedback is gathered the more time and money it will take to change, but rather than dismiss it out of hand, look at whether there would be a suitable return on the investment.

A couple of pointers about gathering feedback. If you have a demonstrable application, consider using a video camera or for web based software a service such as CrazyEgg to record how the user interacts with the screen. In Predictably Irrational: The Hidden Forces That Shape Our Decisions, Dan Ariely carries out controlled tests that indicate how we make decisions based on certain environmental conditions. One test he has people select a free sample of beer from a list of four different beers, some with exciting descriptions, some with dull. When people publicly make their choice, they are more likely to choose a beer that hasn’t been selected by someone else at the table that choose the one that sounds the best or the same beer is chosen by each person at the table (this may be a cultural difference). However when the selection is made privately more people chose the better described beer.

I’m not suggesting that you ply users with free beer, but I am suggesting that you collect information privately possibly using a feedback form. The feedback shouldn’t be anonymous as you may need further clarification, but by removing any social convention by making comments publicly you will get better quality feedback.

To highlight the need for user input, a few years ago I wrote an application called Restoration Manager that helps locate parts from a vehicle that’s being restored over time. Having spent many hours searching for parts I had removed from a car weeks earlier, thinking I would be putting it back on in a couple of days, I felt I was in just the right position to design the software. A mate of mine who is an engineer and spends his days restoring cars and bikes and who doesn’t use a computer a great deal offered to test an early version, which was a good job as I was wide of the mark in some places. Interestingly I recruited 10 testers for a later release with the offer of free software and despite their initial interest only 3 actually downloaded the software and only 1 actually fed anything back, which was to do with the installation routine.

36 Common Software Development Mistakes
9. Lack of Project Sponsorship and Buy In

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

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.

Deployment Woes

Published May 16th, 2008 in Development, Techniques | No Comments »

I’m unable to continue the classic mistakes series again today due to a problem one of my private clients is having with a software deployment. To help them hit their delivery date I’m rolling my sleeves up and attacking the problem, as Marku Alen, one of my rallying heroes from the 1980s’ would say “Maximum attack ! 110 percent!”

Typically some, if not all, of the problems could have been avoided.

  • A merge from 2 code streams into another code stream had taken place just prior to the building of the software. There was no time for testing, not even the stored procedures have been compiled. The script to compile stored procedures into the database is failing in numerous places
  • The deployment is split into two tasks, handled by two different departments. The department that handles the creation of the install kit using Installshield has one person that knows how to do this, and he’s on holiday
  • The comprehensive operations manual hasn’t been updated for over 12 months, despite changes to the file server locations and an upgrade to Installshield 12
  • An error produced in Installshield allows the MSI to be produced, but locks the files Installshield produces preventing another MSI to be generated in that directory. So every time the MSI is produced another directory has to be created and the necessary files copied over. This may have been overcome, but hasn’t been documented by the chap that normally handles it

How this could be avoided:

  • Merging is a horrid task, very boring and easy to get wrong. In this case what should have happened is a merge from one code stream into another, fully test, or at least a smoke test, merge in the second code stream and fully retest. In adds 2 to 3 days to the merge, but it provides confidence in the application that currently isn’t there. Bearing in mind that this is almost a release candidate, releasing unstable code at this stage is foolhardy
  • As a general rule never check code into shared source control system when that code doesn’t compile. There are downsides to this approach, for example amended code only existing on the developer’s computer for a period of time, but this risk can be minimised with a comprehensive backup plan. When you have more than one developer working on a code stream, I believe checking in only code that will compile is vital to prevent developers wasting their time getting someone else’s code to compile. The same applies to stored procedures
  • Keep operations manuals up to date. The idea is that just about anyone in the development team could pick up the manual and produce, in this case, application binaries and the setup kit. Additional information, such as problems with Installshield can also be added to a departmental or company wiki

Interesting Postings

Published May 15th, 2008 in Development, Miscellaneous, People, Techniques | No Comments »

I was in London all day yesterday and today has been spent trying to get a software release together and an odd error in Installshield is preventing this.

My usual buffer of postings has been exhausted, so today I’m going to post links to some other blog entries.

If, like me, you don’t like fingerprints over your screen, you will agree with Jeff Attword in his post on the subject. A bit extreme, but I know where he is coming from! www.codinghorror.com/blog/archives/001115.html

The second is from Steve McConnell. He’s carried out a survey on the classic mistakes presented in his Rapid Development book, which are the basis of the current series on this blog. The survey can be seen here: Classic Mistake Survey

Steve has also updated the Classic Mistakes list recently and we will cover this once we’re past the first 36. The 7 new mistakes are list on this post: Classic Mistakes Updated

36 Common Software Development Mistakes
8. Unrealistic Expectations

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

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.

36 Common Software Development Mistakes
7. Relationship Between Developers and Customers

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

In Rapid Development, Steve McConnell talks about friction between these two parties rather than relationships in general. Friction implies some degree of animosity and detrimental effects on a software development caused by developers and customers communication aren’t always as a result of disagreement. To be honest, and with one exception I’ll come on to in a minute, I think generally developers and customers should be kept as far away as possible, unless there is a chaperone. With massive generalisations, so there will be exceptions, here are my reasons:

  • Developers speak another language, so do customers. Neither can accept why the other doesn’t understand so you need an intermediary that can speak, or is willing to lean, both languages and translate. I’ve just had a very good example of this where I’ve spent nearly an hour on the phone over the last week helping a customer buy and download our restoration software. He uses the computer as a tool and the vagaries surrounding accessing a hyperlink in an email is of no interest and outside his area of knowledge. Repeatedly stating “click on the link” isn’t going to get anywhere
  • Developers like creating new, exciting applications. Having to make changes is viewed as mundane and bound to be met with derision and much tutting
  • A 3 month development is short for developers but a lifetime for customers, particularly if they have seen a perfect prototype. Software people know that an application is like an iceberg with the GUI above the water and most of the code below, but customers focus on the bit they can see
  • If a customer desires certain amendments to an application that is being developed that is time consuming to include, if the developer makes the decision to include it, this may be made without considering the scheduling or financial implications of doing so
  • Ideally developers should not be the first line of support as this causes interruptions and also different categorisation of problem severity. The customer may class a problem as high severity as it’s reducing their efficiency, but if the developer sees it as a tricky or dull change the severity may be reduced. Conversely customers often see all problems as top priority and want them fixed immediately

There is one exception. I strongly believe software is better when the people designing and building it have some knowledge of the business or industry it supports. I worked for British Telecom just after privatisation and the day I spent looking at different sorts of exchanges was one of the most useful days I have had. All of a sudden the huge billing system I was working on made more sense. Just knowing some of the language the engineers used on a day to day basis improved the quality of my work. Arrange days out of the office for your team and immerse them in the business they are producing software for. They will understand the customer requirements better and will benefit from a day away from the office.

36 Common Software Development Mistakes
6. Poor Office Environment Part 2

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

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.

« Previous Entries