The Quick, Small change

Axiom: There is no such a thing as a quick and small change to a program.

Unless you're a one-man team with a simple program, every change is going to cost you time, debugging and possibly bugs and frustrations.

Let's take an easy change: remove the extra period at the end of a sentence..

This is something a Project Manager may even be able to do by themselves, if they know how to use the Version Control system. (In a future post we'll discuss why you never want to allow your project to proceed without some form of Version Control.)

So, what could go wrong? Nothing... unless you have Automated Test Scripts and/or a multilingual project.

Your Automated Test Scripts may fail, since there's a missing period, based on what they were trained to check for. This should cause the QA person in charge to come banging your door down requesting an explanation as to why a change was made without a Change Request.

If you also have a multilingual project, the translation of the original may be lost. This will either cause an expense to re-translate the sentence, and/or cause the next version to be released with a missing translation.

So now we've learned our lesson, and we first open a Change Request ticket.

Opening the Change Request will take time, as you have to specify where precisely the change is. You will also be notified each time the Change Request changes owners.

The Change Request then will either be assigned to an engineer or a Task Queue. The engineer will eventually stop something she is doing and make your quick fix. Then she will go get a coffee - since she's anyways interrupted - and an hour later she'll be back into her originally scheduled work.

An hour? What was she doing for an hour?

She had to read the Change Request, find the correct file, check-out the latest revision from the Revision Control, make the change, do a Diff on the file to ensure nothing else accidentally was changed, and then Check it back into the Version Control and compile. She then had to assign the Change Request ticket to QA to be tested and the Automated Scripts updated. By now she has completely forgotten what she was working on, and will have to get back into her original project.

QA now has to read and understand the change, update the test plans, sanity check the change to their code and to the product, and assign the Change Request ticket back to you.

That's a lot of time for a tiny change.

If your Change Request also involved changes to the logic or the flow, then you can be almost guaranteed that it will affect something else. This means that besides for a tiny change, the programmer needs to check the overall logic, as well as related functions that may be affected. If the programmer did not think of all possibilities - and adjust them as needed - then QA will open bugs, and then your tiny change becomes a mini-project.

So how do you ensure that as few changes as possible are made? That's where a full Functional Spec with exhaustive Use Cases is useful; more about that in another post.

- Danny