This question came up again and it reminded me of a project that I was on, years ago. In that project, the criteria for “done” had not been defined, so nobody could tell whether anything was “done” or not. You just had to have a gut feeling and hope that it worked-out. Like Christopher Columbus: head west and hope that you don’t fall off the edge of the earth. When you land on N. America, just refer to the local people as “Indians” (because you think you are in India) and consider yourself “done”, until you hear otherwise.
This time around was a little different. The task I had been given was a 3-day task. Last time that I touched it, it had been “done” five times over the past seven weeks. People were starting to ask when it will be “Done done”. I was wondering the same thing.
When I was first handed this task, I was given a block of code and several stored procedures. They were from an old system with (old) data structures. My task was to upgrade them to use the brand-new data structures. — The end –. Those were my instructions. No business rules, no diagrams, just code and stored procedures. Go get em!
Me: “Sailing westward. Yes sir!”
It took me a few days to figure out the names of the new servers, find the tables and match things up. I queried that DB with the relentless determination of an inquisitive four year old. Three days later, I actually got it done. Bam! (We can call this “done #1”)
When I reviewed it with a DBA (database admin), I was asked why I was using each of the tables. I walked the DBA through my mental process for matching column names and was quickly cut-off. “Um, no. The tables that you want to use are over here. These tables, which you are using, are intended for something else.” Oh gosh, I wish I had known that before I had started. It would have saved me two of those three days. No problemo. I will just switch those out and make it right. This will take another day or so. No sweat.
Oddly, those new (correct) tables didn’t have much data in them, and some of the columns didn’t exactly match up correctly, but I could see what was happening and I could understand why. After all, I was working a “dev” database. I didn’t expect perfection. So I needed to synthesize (make-up) some data for an empty table or two. Hopefully, I guessed correctly. A day and a half later, I wrapped up the changes, completed my re-test and returned to the DBA (done #2).
The DBA was in a hurry, so after a quick once-over, I was told that it looked good. (still win #2)
I was feeling optimistic at the end of the week. We ran it against the test database and it worked without a hitch. Yes! (done #2 is looking like the end).
Next week, the users were excited to get their hands on the converted data and dove right in. Four hours into their testing, there was no news (which is usually good news). I didn’t celebrate early because I didn’t want to jinx myself. Unfortunately, after lunch, they found flaws and reported them. Victory was averted because “there was no K data”.
None of the data had any specific meaning to me, so I didn’t realize that there was supposed to be 27 rows for the K data. I had J data and L data and M data, which made as much sense as anything else. No K data though. Sure, I can’t believe I missed something so arbitrary. I was trying not to sound like a smart alec when I asked, “If K data is missing, what about N data or H and I data?”
…”wait a sec, you mean there is no H or I data?!” “What is N data? It sounds like you are making stuff up now. Don’t do that.” “Why is the H and I data missing?”
The DBA and I took a closer look at things. It was determined that the K, H and I data had not been loaded yet. The DBA loaded that data for me and it revealed all sorts of things that weren’t there before. Suddenly, there were new business rules for me. Back to the drawing board.
It took several days to overhaul things to accommodate the complexity introduced by the new data. I am no stranger to complexity. I sometimes eat complexity for breakfast. I put it on my oatmeal by the spoonful. Boo-yah! So, after three more days, I was ready for testing again. (done #3)
Well, I hate to sound pessimistic, but you can guess what happened, can’t you? More new data, more new business rules, more things I didn’t know two days ago. Back to the drawing board. Again.
(repeat two more times)
The deadline had passed and some people were getting irritated, maybe even irate. I was allowed to sit down with the person(s) who understood what the original data meant. We went through my queries, line-by-line. I drank from the fire hose, but actually got to the bottom of it. I think we burned up 12 hours ironing it out, but in the end, it was finally “right”.
It didn’t feel like a victory, because I was past my deadline. People were happy that it was (done) done, but they would have been more happy if it had been (done) done, sooner.
Moral of the story
If you’ve been a developer for more than 3-4 years, there is a good chance that you have been in this situation. You can feel the tension building, like the wave of nausea and the few gags that hit you right before you lose your lunch. You can feel it coming. You hope it won’t be that bad, but you know it probably will be.
So, how do you handle or prevent this flu-style development process? There has got to be an IT equivalent to [starve a cold, feed a fever] or maybe a flu shot or something.
It all stems from not knowing what “done” means, (before you do the work).
As I was working on the project, I thought I knew what was meant by “done” each time. However, I did not. There were not 5 definitions of “done”. I started with incomplete information and I ran-off and started programming. Believe me, it wasn’t all my idea either. Everybody was very busy and nobody had the time to hold my hand and explain it all to me. I’m an experienced programmer, so by now, people expect that I must have developed ESP or special ninja powers or CIA mental wiretapping skills or something. If not, then I should have spoken-up. Some of that is my fault. I should know better. Unfortunately, when people start screaming and running around, I feel obliged to start running and screaming too, even if it is not the right thing to do.
When you really consider what happened, (in the end) somebody actually did have to sit down, hold my hand and explain it all to me. It was unavoidable. It just got postponed until after my deadline and after I had programmed the solution five times. So, taking a shortcut didn’t accomplish anything, but it did waste my time and the testers’ time.
Solution to the Problem
As a professional who cares about quality and [meeting deadlines], I’d like to avoid that mishap again. So, the next time I face this kind of situation, I need to have the discipline to do the correct thing. However, if you don’t know the correct thing to do, then you probably won’t guess it on the first try. You might get it on the fifth try. Maybe.
The correct thing to do is always this:
Before you start programming, write down the criteria for “done” (to the best of your understanding) and submit it to your boss (and anyone else who cares about the outcome).
The criteria for “done” can always be summarized by: a test plan.
It sounds too simple, but it isn’t.
Somebody out there is going to look at the results of your work when you are done. That person is going to use/run your stuff and observe the outcome. Some of it is going to be pretty obvious, simple stuff, but some of it is going to be subtle sneaky conditions and exceptions to the rule that only happen during the third equinox, when Jupiter aligns with Mars and the queen is wearing a blue hat (or equiv. weird rules).
If you have a test plan that talks about EVERY-ONE of those conditions, then you will be able to write your program to handle it and you will test it yourself. For starters, you will confirm that you have a list of IDs (pk values) and account numbers and fake customer accounts and imaginary user records, etc. that are ideal for testing those conditions and proving that your program works (as expected). More than that, the expectations will be written down and handed to the boss.
Here is what your test plan should contain:
- Pre-conditions – What will the data look like before you start? How will you put-it/restore-it to this (un-processed) state before you run your test (or after/before you re-run your test)?
- Tests – Itemize each individual business rule and exceptions. This might require you to split this document (with pre/post conditions) into several documents. Some things that you will want to explicitly mention:
- IDs of existing data to watch. It is like a RFID for your data. If you have thousands of rows, and this test doesn’t apply to all of them, then identify one specific row that can be monitored to determine if things went right/wrong.
- Roles/accounts. Some permission sets are required to work/function differently from others. Split those into different tests and describe (in great detail, or pictures) how things should be different from other accounts.
- Post-conditions – What will the data look like when your program has run correctly (or incorrectly)?
After your testing is complete, if some expert steps forward and identifies a flaw in your program, you can politely introduce that person to your test plan and ask what is missing. Then you add a new test condition to your plan, so you never miss it again. The boss will see the pattern and eventually ask the expert to maintain the test plan with/for you. Guess what? Now you have your requirements and the boss will have his expectations set. No more surprises. No more blaming you.
Now, when anybody asks when it will be “Done done”, hand him your test plan and tell him that your program will do everything listed in this test plan. Therefore, the program can only be “perfect” when the test plan is perfect. As long as your test plan shows a respectable effort on your part, your butt is covered and the boss has something to go-with and build upon.
Oh, and by-the-way, don’t expect anybody else to write this test plan. Nobody else’s butt is on the line, so nobody else needs to care. YOU need to care. Which means that you need to write the plan and make sure it completely encapsulates “Done done”, (but avoid using that term unless the boss says it first).
Writing test plans is a pretty un-common practice for developers, but guess what? It is one of the habits of highly successful (and elite) developers.