I’m a software developer. If you are not a software developer yourself and have never even met one, you have probably no idea what I do.
So let me tell you how my world works.
Let’s say a client comes to you and asks you to build a catapult that he wants to use to catapult cows (well, usually they ask us for things that make a bit more sense, but let’s make it cows and catapults for the sake of example).
This is what we call a general requirement.
So if you meet your colleague at the elevator and he asks you what you are working on right now you can use this to give a brief but accurate description of your current project: You are building cow catapults.
In turn, you would be pleased to know that your colleague had recently built submarines for rabbits, so now you both can exchange your experiences on animal transportation and don’t have to travel in the elevator in awkward silence.
Later, your client also tells you that:
- The catapult should be pink with blue stripes, have three wheels, always face west and be able to catapult cows of green, yellow and red color.
- Depending on its color, a cow should be:
- either catapulted immediately to its destination (if green)
- put under a full body scanner and catapulted only if the scan results turn out ok (if yellow)
- or catapulted straight outside the perimeter (if red), because our client doesn’t need any red cows around.
- However, if a red cow is wearing golden boots, it’s a VIP cow that needs special treatment.
These all conditions put together make the requirements specification.
Put into a fancy document with a lot of pages, it makes a requirements specification document, or shortly, the spec. If you are lucky, the spec also contains the exact description of the required behavior of your catapult for particular constellations of cows, colors and footwear (for ex., a green cow wearing blue boots should be immediately catapulted to its destination).
These are called use cases and are as helpful as they are rare to be found within a spec. Although they can be a great help for you to figure out, whether your catapult works according to your client’s expectations before it’s too late, they take a lot of time and effort to put together (think of all possible combinations of cows, colors, boots and body scanner outcomes), and your clients has better things to do than to write it down for you to make your life easier.
So you start developing (this is what we call the making process) your catapult.
But before you even get a chance to paint it pink, you find out that the boots of the cows don’t come with the cow but will be provided from a local shoe factory that belongs neither to you nor to your client. This is when you have a third party dependency.
Besides, this factory has not opened yet and will open only in a week, so there is no chance for you to start doing even the simplest tests of your catapult to know if you are moving in the right direction, as the cows without the footwear can’t be catapulted (because otherwise they will catch a cold and die, see the spec, page 7).
So you quickly make two pairs of house slippers out of paper, paint them blue (ordinary cow) and gold (VIP cow) and put them on one cow at a time as you are doing your tests. This is what we call a mock implementation. It’s not what it is supposed to be at the end, but it allows you to test other parts of your catapult while you are waiting for the shoe factory to open.
Ok, let’s fast forward.
Your catapult is ready, you tested it as good as you could taking into consideration the amount and variety of cows and footwear provided by the client to you for the test purposes. If you think you have the worst behind you, you cannot be more wrong.
Now you installed the catapult in the client’s yard (or as we called it, client’s testing environment), so that the experienced workers from the client’s site, who are certified in air transportation of animals in general and cattle specifically can try out your catapult before it will be used on real cows (or as we call it, goes in production).
The client has a system where they can report everything they think they found to be wrong with your catapult. To report an issue, they document it within so called ticket, which is supposed to have a title that makes sense, a description both of an error observed and correct behavior expected. This ticket will be then assigned to you for fixing.
There are three kinds of tickets: a bug (indeed a malfunction of your catapult that is totally your fault), a change request (client wants you to change an existing feature a bit) and a feature request (client needs a completely new feature that was not required before).
While you are going to fix the bugs on your own money, the CRs and FRs will be paid for by the client. Now you can guess what kinds of tickets you are going to get the most.
So, as you now know everything you need to understand the world of a software developer, let me tell you how my week was so far.
We have installed our catapult at the client’s yard months ago. But clients are also people, so they do the stuff that is not fun like everybody else: five minutes before midnight; and by five minutes I mean 3 days, and by midnight I mean their deadline when they have to have the catapult ready and catapulting real cows.
They tried it out before, of cause, but more in a way of “Pink? Check. Stripes? Check. Looks great, guys! I think we are good”. But suddenly, three days before the catapult has to go out into the real world they got like 10 people testing 24/7 and catapulting 100 cows an hour.
So we start getting notifications of the created bug-tickets (i.e. reported errors) with the speed of the twitter updates. I think at some point I had 40 new emails in my inbox.
My first thought was, “Oh my God, we screwed up big time. Guess who will be riding the catapult now instead of the cows!” Well, good news was that only like 5 of them were real errors that I had to indeed fix.
Bad news was that in these cases you can’t know it in advance and assume that all of them are errors that need fixing.
But let me tell you about my favorite “errors” reported by our clients first in their somewhat unique style:
1. “It doesn’t work. Please fix it.”
What I wanted to reply: What, what doesn’t work?!
What I actually replied: Could you please specify more details regarding the observed and expected behavior? Unfortunately, it is not clear to us from the current description.
2. “Cows wearing ties not recognized as VIP.”
What I wanted to reply: Yes, because you told us the VIP cows will be wearing golden boots! How come it’s ties now?
What I actually replied: According to the requirement specification, p. 15, a VIP cow can be recognized by its boots being golden. Unfortunately, we couldn’t find any place in the specification document where cows should be checked for ties. Thus, we consider this to be a change request with an effort estimation of 8 hours for its implementation.
3. “Cow number 123 is stuck and not flying.”
What I wanted to reply: Because it’s not a cow, it’s a half of a horse, purple and naked. Catapult is puzzled and doesn’t know what to do with that.
What I actually replied: Our analysis shows that you are trying to catapult half of a horse and not a cow (see picture attached) that shouldn’t be allowed as due to the specification document, p. 2. Please try again with an animal of proper breed and size.
4. “Cow number 456 lost its boots during transportation. See video attached.”
What I wanted to reply: I saw the video attached, three times, one in slow motion. Boots are there, cow’s smiling and waving its front hooves at you. I also checked the raw test data. Everything is fine. What are you talking about?
What I actually replied: After analyzing the raw test data, we couldn’t confirm your observation. The cow is still wearing the boots. Could you please explain how you reached the conclusion that the cow’s footwear has gone missing?
5. “Cow 789 is wearing the boots of different colors.”
What I wanted to reply: Does it say “shoe factory” on my door?
What I actually replied: Please address this issue with the representatives of the shoe factory, as the cows come to us ready for transport with the boots on, i.e our catapult can neither add, nor remove, nor repaint the footwear.
And this craziness has been going on since last Thursday actually.
Couple of times I was simultaneously on the phone with the client, looking into the raw test data on my pc analyzing a ticket, and answering a question of my colleague with head shakes and eyes rolling. My longest lunch break was 15 minutes (a sandwich and a cup of coffee in front of my monitor). I was regularly leaving office after hours.
One day we told them that 3 pm is the deadline to find and report the issues, otherwise we won’t have enough time to prepare a new version of the catapult by next day.
It was suspiciously quiet, so that I even thought it was not at all silence before thunderstorm but finally a normal day where I finally get to go home at 6 pm. A rookie mistake, as at 2:56 pm our client managed to report five more new issues within three minutes, which needed to be analyzed the same day.
I bet they were sitting at their desks doing the final countdown till 3 pm all together.
We got lucky these all issues turned out to be not real errors. Although the testing specialists on the client’s site remembered that they shouldn’t try it with half of a horse, they thought, what the hack, nobody said anything about two thirds of a zebra and an apple. Although they knew that when the boots are of different colors they should talk to the shoe factory and not us,it must be totally our fault that one cow was wearing flip flops. The flip flops were both the same color, so…
Well, we managed to prepare and install the upgraded catapult ready to perform with the real cows in time and it has all been going all right so far.
By the way, it is our favorite client our company has been working with for years. They even let us do lessons learned meeting with them after this kind of a run, and we are totally allowed to tell them that we were not thrilled by the fact that they were trying to catapult half-horses, or that they kept coming to us with the boots problem.
They will make a sorry face, swear not to ever-ever use half-horses again and always check whether an animal that is refuses to be catapulted has all four hooves in place, an udder and horns before reporting it as an error.
We will pretend to believe them, but we all know they are going to do it again. Not because they are mean, but just because they will forget. But other clients are much, much worse, in many ways.
Anyhow, tomorrow is Friday, and it will be the second day our pink catapult with blue stripes facing west has been operating with real multicolored cows in stylish boots in the real world.
What can possibly go wrong?
Or by the way, did I tell you, if they find a problem with the catapult that is in production and not the test environment it will be much, much worse, in many ways?
Man, I should have taken vacation when I had the chance.
See episode 2 of “Life of a Software Developer” here.