L-P Huberdeau's blog

I believe any developer can deliver a bug free application. No need for unit tests or any kind of heavy-duty techniques as written in the textbooks. Applications always work on the developers machine. What kind of fool would deliver, or mark as completed, something he couldn’t get working? The problem is that there are many steps between the end of development and the production use by the end user. One of these major steps is deployment. There is always a tiny dependency on a library you forgot to think about, a minor version change in a library that should be compatible, but appears not to be, a small configuration flag you forgot to transfer. These errors are always hard to find, and mostly make you look like a fool.

Once you get past that terrible deployment phase where users reported a bunch of “bugs”, which are in no way part of your new system, they start having improvements to propose. Academics will tell you it’s because you made a poor job at collecting requirements. I consider improvement requests are part of the normal development cycle. You can dig into requirements for months, obtain a concensus on what has to be developed, you will still end up with tons of requests. Requirements based on paper and static needs are abstract. Most non-technical staff have hard times visualizing the final results out of these cold terms, even if they were inspected a dozen times and are completely unambiguous.

This is where the strength of the Agile methods lies: providing users with concrete, working products on which they can comment. As long as, when you encounter one, you notice the fuzzy spots and the assumptions made during the development, you can design in consequence. Leave open doors for future modifications. Don’t lock youself in a static framework. Your design needs to be as agile as your development cycle.

Real problems also come from improvement requests. Everything always seems to be urgent, and it can sometimes be. There is an urge to perform the change and place it in production. This is where real bugs appear in the system. If the change is made too fast, changes are that it will be incomplete. Components of the application that should have been modified to reflect the change have been forgotten. If you’re lucky, the user will report the new problem fast enough and you will be able to link the problem to your recent change.

If you’re less lucky, the forgotten component is part of an infrequent process, a conditional one, or worst, invisible. The problem may only see the light weeks or months after. That’s when it becomes a major problem. At that point, you might not even remember the change was made. If the behaviour was invisible, you’re probably stuck with some corrupted data for which you will have to write a correction procedure. Do I really have to mention this is something you want to avoid?

Process-driven world uses impact analysis to determine what is affected by the change. Since they have a bunch of fancy tools to perform the traceability of their well defined requirements, they only have to perform a few clicks to get the list. Of course, it considers the requirements database was kept up to date and all the links are valid. Once they have the list of changes, they can perform an estimate, submit it for approval, write some more documentation on the way and perform the change.

Impact analysis can be applied in a smaller context where not so much documentation is present, and where not complex toolchain is integrated in the development cycle. The person who wrote the application is probably in the best seat to determine what are the technical impacts of the change. It can be done very quickly, within a few minutes.

When I got in the office one morning, the project’s sponsor came up to my desk to ask, among other things, what were the progresses on the project. The situation was a bit like this.

• Mr Sponsor: So, how is the project going?
• Me: Quite good so far, only a few approval steps are missing, along with the public display of information.
• Mr Sponsor: Let me grab a copy of the ISO procedure supporting this application and we will review it together

As we were reviewing the procedure to see if all the steps were covered, or if the dating procedure had to be updated, a coworker (non-technical) and potential user, jumped in the conversation and starting to propose changes.

• Coworker: This looks good so far, it will remove a lot of redundancy in my work.
• Mr Sponsor to Coworker: How do you perform step X at the moment? The application reflects what is in the procedure, but it seems awkward.
• Coworker: Right now it’s only a paper form, and I only fill it afterwards because the format forces me to, but if we could pre-fill it in the preparation step, it would definitely make sense.
• Mr Sponsor: Sounds good, I’ll make sure the procedure gets updated.

The conversation went on for around 10 minutes. As they were speaking to each other, I was sitting back taking notes, making a list of all the small changes that were required. Since not all of the discussions were concerning changes, I took some time to list the changes to the database schema and affected interfaces. By the time they were done discussing, I had calculated the amount of affected function points and calculated the estimated schedule impact. We reviewed the list of suggested changes and impact analysis was almost over. Before performing the actual changes, I performed a few greps in the code (as I said, no fancy tools required) to verify if I missed anything, and it was good.

By the time I was done with this, the coffee brigade was passing by, meaning the whole story took under 20-25 minutes.

Of course, this story applies to an application that was not currently in production, so I did not have to worry about loosing data or such. As I worked on that specific project the day before, concepts were still very fresh in my memory and I didn’t have to remember them or think too much about those hidden dependencies. Still, the impact analysis is a valuable tool. It forces you to stop developing for a minute and think about what the consequences are. I usually transcript the changes from my note pad to the wiki for future use. The list of changes can then be used as a checklist to see if all the required changes were applied.

On larger projects with contractual agreements, things might get more complex, but you can apply these things in day to day development without much effort.