Datasheet

Chapter 1
22
Yes, I know it is important. I know that I am as likely to benefit from it as anyone else when I
revisit my code later. I know that the users have paid for it! I know it makes the difference
between a good application and a great application. That's why I do it and why I make sure
that everyone working with me does it and does it well. But I am not going to pretend for a
moment that I enjoy it!
In practice, the best approach to this time-consuming chore is a mixture of notes and in-line
comments made as you write the code, followed by reports and descriptions when you're done.
Then all you have to do is check everything through carefully and keep everything up to date
every time anything gets changed at the last minute!
Acceptance
Ah, the bliss! It's all over and the users love the application you have written for them. Great! If
you have any sense, you will seize the moment and make sure that three things happen.
First, get the users to sign off the project. If you have drawn up a comprehensive requirements
definition and have met all of the success factors identified by the users at the start of the
project, this should be a formality. But it is no less an important step for all that.
Second, get the users to tell their colleagues about the new application they are using. Many
users have very short memories, and it won't be long before the users forget just how bad the
manual processes were that they had to rely on before you wrote this application for them and
just what a difference this application makes. Get them to sing your praises while they are still
hooked. That's when you will get the best recommendations, whether you are collecting them
for your company's marketing brochure or for your own personnel review (and, hopefully, pay
rise) in three months' time.
Finally, get the users to start thinking about the next release. Some features might have been
axed because there wasn't time to implement them; others might have been identified too late
to make it into this release; and others might have always been destined for future releases.
Once you are convinced that the users love the product you have given them, remind them
about what it doesn't do… yet!
Review
The final stage is the post-implementation review. This is the point where you look back at the
project and decide what worked and what didn't, what caused problems, and how those
problems could have been avoided or their impact minimized. Did you hit all of your
deadlines? Did all of the intended functionality make it into the final product? How are
relations with the customer at the end of it all? What state are your developers in at the end of
it all? Given the opportunity, would you do it all again?