bgror

Congratulations

Created at: 13.02.2010 03:03, source: The Life Of A Radar , tagged: Uncategorized

Congratulations! You’ve worked so amazingly hard over the last seven-and-a-half months on this project. You met all the client’s demands as they came in. You completed the project on-time and under the $30,000 budget by $2,000. The client is pleased about that. You can tell by the dollar signs in his eyes. The client is also pleased that they’re able to put the website out to the world to grow and conquer it, it already has a couple of users from the beta invites you sent out earlier in the week. You still keep in touch with the client on an almost-daily basis. He’s saying the site’s doing great.

But.

There’s this one user who’s reporting an issue with a feature you worked on 3 months ago. The client has set up his personal email address to receive the bug reports. You receive them when he gets around to sending them. The page is showing “We’re sorry but something went wrong”.

Uh oh.

You log into the website and check for yourself. Sure enough that page is throwing a 500. But why? This feature was completed 3 months ago and worked fine then, didn’t it? You try it on your local machine and you see that it’s something simple. Perhaps a variable incorrectly spelled in the controller. Or perhaps not. Perhaps it takes you longer than a couple of seconds to identify the issue. Perhaps it takes you an hour, a day.

A week.

So how did this error come to be? You did write tests, didn’t you?

Oh I see.

Because of the impending deadline you were pressured for time and couldn’t be bothered learning any of the testing frameworks. Your boss says “The client’s not paying you to write tests, he’s paying you to write features” when you bring the point up. Even though your Rails knowledge has increased during the life of this project three to four times the size of what it previously was, you still don’t know shit about testing. Maybe’s the time to start to learn you think. Ah, but The Boss doesn’t want you spending time not producing features. “Tests are a waste of the client’s money” he claims. You sigh. “I’ll do the next project better. I’ll get him to see the light.”, you say in your head. Ok, so you didn’t write tests. I’m sure you can use git bisect to go back through the revisions and see which one broke it, right?

Oh I see.

You use SVN. That’s fine too. You’ll just have to find another way to go through each revision and find which one broke it. I’ll see you tomorrow when you’re getting close to that goal. Maybe next Wednesday you’ll figure out that it was r348 that broke it, the current trunk is r2343. Have fun with that.

You fixed it. The bug is defeated, sent to the depths of Hell along with one eighteenth of your sanity. That was quite a toughy. You did write a test to ensure that it wouldn’t happen again, right?

Oh I see.

You commented on the Basecamp todo item saying that it was fixed. I guess it has a searchable name, right? Just in case it comes up again? It’s called “Something went wrong”?

Uh oh.

So you go home, satisfied that you kicked the ass of a bug that had been on your mind for days. You win.

Congratulations.

The next day you wake up, grab your coffee/milk/orange juice and check your emails. There’s 3 from Facebook, a couple from a few mailing lists you subscribe to and fourteen from your client. These aren’t fourteen love letters. You see the first one was sent to you 20 minutes after you went to bed. If only you had stayed up later. You will tonight, just that extra 20 minutes since that’s when the client comes online.

You read the first one. It’s a bug report. So is the next one. And the one after that. And the one after that. And guess what? The one after that, too.

All fourteen emails your client sent to you overnight weren’t “Thanks for all your fabulous work on the site” they were the “Why the fuck is this shit broken?” kind of language. He paid good money for it he thinks. You are happy being paid $20/hr. It hasn’t been long that you’ve been doing this anyway and you have to start out somewhere.

Congratulations.

You now have bug reports to deal with when you get into work this morning. 8 hours in a day, with each bug taking you 30 minutes to do. Easy, with time to spare. “Pfft. Done by sundown”, you think. You realise that one of the bug reports that got sent in was that bug that you fixed the other day. Another developer working on your project had a conflict with the file and accidentally put back the broken code instead of the working code. Ok. That’s fine. You’ll fix that one too. You have a 2hr meeting with another client at the beginning of the day, leaving you with only 6 hours to fix those bugs by sundown. You spend an extra half-hour at lunch. Five-and-a-half-hours. But by lunch you’d already “killed” four of them. You were a bit groggy this morning and you think that lunch will cure that feeling. You’ll conquer the other ten this afternoon.

You don’t.

You finish four, maybe five of them leaving eight, maybe nine bugs fixed. The client is not pleased. You have only done some of the work. He expects a 7-day-a-week-24-hour-all-the-freakin’-time response.

Because you’re his bitch.

Alright. So your boss gives him a large apologetic email that you will try harder in the future to meet all of his demands because you don’t want to lose this client. He’s invested $30,000 in this company already and with “Version 2″ of the site “just around the corner” he’ll probably invest a lot more.

So you’re back to fixing those remaining bugs. During the night another three have come in. Your bug count is now eight. Eight hours in a day, eight bugs in the list. Done by sundown. You complete seven. You’re exhausted. They took you all day to debug. You email the client and say that you’ve only fixed seven of the eight bugs. He emails you back, naturally twenty minutes after you’ve gone to sleep saying that the eighth and final bug “makes the site unusable”. Your boss brings you in in the morning and says that your work isn’t good enough. You baulk at this suggestion. You claim to have fixed thirteen of the fourteen bugs the client emailed you earlier in the week. Today you’ll have completed the fourteenth one, you’re so confident about that. He naturally asks why there were fourteen bugs in the first place. You don’t have an immediate answer. He continues on his rant about that you should be testing the code each time you deploy it. Go through the site and make sure that it’s ok. The boss continues on his tirade for an hour. You try to counter his arguments but you view him as some sort of “higher-being” and due to your lack of experience you can’t fault him. He’s the boss man after all. He got there somehow.

Your company has accrued all this technical debt that you didn’t budget for. This carries on for a month longer and now the client has gone over his budget by $2,000. $2,000 he never wanted to spend. He’s talking about leaving your company and moving to another one who could do a better job. This is probably the case. Your boss brings you in and tells you what’s what with this project. The client is leaving. The next day he fires you.

Congratulations, Freebird. You’re out of a job and very, very nearly out of money. A couple of grand is all you have left. Time to begin that hunt again.

So how do you prevent something like this from happening?

You eventually get a new job working with a new company. You sit down with your new client and you do it right. You spec out their application using something like Pivotal Tracker. You write tests religiously for every single story in Cucumber. There isn’t a story without a test. This reduces technical debt in the long run. You won’t have as many bugs like you did when you didn’t test with the previous application. You will have bugs, though, but you won’t be spending those long nights fixing them because you have tests covering it all. The tests will show you where something went wrong because more than likely, a broken part of the site also means a broken test.

So you start off on a simple story such as “User login” and you write a cucumber feature for it with two scenarios. One for logging in. One for logging out. You’ve written all the steps for it but some of them are not implemented, others are just plain broken. That’s because you haven’t written any code for it yet. This is called Behaviour Driven Development. You’re going to be learning it, and you’re going to do it right from now on. You implement each step one at a time and eventually your feature is all green. Why do you do this? So future-you doesn’t come back in 3 months and see that this feature is broken. Bonus points if you’re using a Continuous Integration server to ensure that this feature and its eventual brothers stay green. A broken build means a broken application and your goal if that build is broken is to make it very, very unbroken.

Congratulations.

You can now mark that story as “Finished” in Pivotal. Then you can deploy it to a staging server and mark it as “Delivered”. The client then can log in to Pivotal and see that the story is marked as “Delivered” and then log in to the staging server, test that feature and press that “Accept” button. You want to be seeing green stories in your Pivotal list. Green is the colour you want to be seeing everywhere.

So the next feature comes along and involves some rather complex controller logic that returns a JSON hash. You can write this also in Cucumber, or you could write an RSpec Controller test. Either way, you’ll write the test first and then the code. Then it’ll pass. Then you can refactor the code (unless you write awesome code (hint: neither of us does.)) and it’ll still pass. Sure it will feel slow at first, but that’s because you’re learning how to do it. Don’t fight it. It will save you a lot of time in the future, where it’s most important.

Eventually after the next seven-and-a-half months you’ll have all these Pivotal Tracker stories all green in the “Completed” section and maybe one or two in the “Backlog” that the client wants done for next release. You’ll run all the specs on your system. They’re all green. You’ll run all the features. They’re all green. You deploy to the staging server for the last time for this release. The client loves it. You deploy it to production and send out the invites. Everyone loves it.

But.

There’s a bug. This time however you’ve installed something like Hoptoad so in your inbox you’ve got the error there. You are the support team for this application. After all, you’re still working for a small company. It contains stacktrace and you can see where it went wrong immediately. You write a test/feature to ensure that this bug would never happen again. It fails because you haven’t fixed the bug. The error is the same one as in the Hoptoad email. You fix the bug.

Congratulations. You’ve successfully regression tested a bug. This bug never happens again for the life of the project.

The client is happy. Your boss asks if he can have a chat with you. You’re doing an awesome job. The other guys were previously on a higher salary than you. Now you’re equal. The client wants more work done on his application. He’s flying your boss to America next week. They’ve specifically requested you to go along too, as you seem “switched on”. Later on in that month, the client invests a 7-digit fund into your company. It grows. Massively. You bring on another ten guys over the next year just to work on this application. You and a couple of the other “Originals” teach them all you know about your application and the process you’ve helped develop. They then go on to teach the other twenty people you hire in the six months following.

Congratulations. Now you’re doing it right.