We're 90% Done!

We're 90% complete with X and we'll be done in no time!

We all know it never happens that way, yet we hear it regularly, most of us have said it, and some of us have said it more than once.

Why does this sort of thing prevade software development?

Most software developers break all projects into two distinct pieces: the Functionality and the Look & Feel. Developers - both current developers and developers-turned-Managers - tend to focus on the first part. Many work hard to develop requirements, create beautiful class structures, refactor like crazy, normalize the database, etc, etc, etc. Most of these things are the skills which developers have a strength in, can measure with different profiling tools, and allow us to check off requirements. Or in other words, they're measureable.

Developers tend to not worry about the Look & Feel thinking "that will work itself out". Duane eluded to this tendency yesterday in Good Software has Users. Until we put a somewhat functional system in front of the target user, we don't know what other work must be done. We don't always understand the workflows, the user preferences, and the general work environment. This is just as important - if not more important - than making sure the tool works effectively.

For example, I have recently been working on a large-scale system which takes input from seven different external systems, allows a great deal of user customization and modification of the data, and outputs the information to up to 65 different systems. [I apologize for the vagueness, this system offers a large competitive advantage and is still under development. - kc] This was immediately broken into three distinct pieces, the first and third which were completed quite quickly and effectively well within the time allowed. The second piece - all of the User Interactions - had a basic version up by the deadline.

Unfortunately, the users had barely used it by that point and never in a production environment. Therefore, once they started getting into it and playing, weaknesses were found, new use cases have appeared, and general oddities - which our eyes simply missed - have now cropped up. The underlying functionality of the system has changed very little, but the presentation, methods to manipulate date, etc. have changed dramatically over a very short period.

How can we - as software developers - prevent this from happening? Answer: Learn how to steer the Titanic. When there are unknown obstacles out in front of the team, we need to steer around them. The best way to do this is to detect them early and only have to change direction slightly. The later we detect the obstacle, the bigger the required course correction and greater risk results.

If we can put the system - even screenshots and static content if necessary - in front of the users on a regular basis, we can get user feedback much earlier, make the user feel involved in the process, speed the time to deployment, and make better assessments of the development status.

That's why I use the Titanic comparison

I believe that steering a project is like steering a boat. You have inertia in the direction you're going, you have a wake in terms of other projects/groups/etc which are being affected, and *most importantly* tiny adjustments earlier can have huge impacts later on.

If the Titanic reacted to 100 feet sooner, what would have happened?
How about 1000 feet sooner? A mile? Ten miles?

Detecting these problems early - most likely by evaluating things regularly - allows the team to react more smoothly and expend much less effort.