How to install a shower battery (guide for programmers)
So you’re a programmer. Life is fun, everything is peachy, and you are allowed to complain about bugs in hardware all day: that’s not a segmentation fault, it’s a hardware bug!!! But sometimes, life decides it wants to be a bitch and kicks in with sounds of water dripping.
Say you’re in the middle of your X-Men marathon, like I was this morning. Not really middle. Let’s say you just started your X-Men marathon, and went for a short bio-break. And you hear water dripping. You don’t get what happens (it’s always the neighbors’ plumbing that’s broken, them savages!). So you go back to your X-Men marathon.
But after a while, you hear noises that make the dam breaking from X2 feel like a silent symphony. It’s the moment when real life really kicks in, and you have to decide what to do. You close the shower in different positions until you have the least water leakage, and you watch the movie until the end. SHUT UP, plumbing, I’m trying to hear things exploding here!!!
Next step is only natural. You put your hand on your phone, call the plumber. Get some over-enthusiastic “I’m at the bar now, I’ll be there in two hours” (coincidentally, that’s how long X-Men: The last stand lasts). Rejoice. For a second, think about some solutions to that loud water dripping. Cut the water from the main faucet (or faucets if you have more). Rejoice again. Call the pizza place, order the Tabasco sauce and your favorite pizza. Rejoice again. As you can see, fixing the shower battery includes a lot of rejoicing.
Four hours later, call the plumber again. He’s upset. Very upset. “You’d expect me to come there right away, huh?” At least that’s what you think he’d say, but you’re not sure, because he makes your phone stink of alcohol via airwaves. He’ll be there in an hour.
Two hours again, in the middle of X-Men: First class you realize the plumber will not be there, it’s weekend, and you have to buy a new shower battery anyway. Unlike normal hardware, you wouldn’t want to buy components, you want the whole thing, at about 50$ the basic model (maybe less, maybe more, I went for a bit more for no good reason). Head back home. Admire your purchase. Rejoice.
By now it’s 19:00, and you feel like the alcohol was a better proposition than work for the plumber. Alas, there is a solution. You can do it. I know you can do it!
Now, before every programming project you choose a methodology. Since you don’t know hardware, your methods will be mostly exploratory, searching for solutions as you find the problems. You have to be agile. Let’s do it the SCRUM way.
So you create your backlog, and see that there’s only one item on the backlog. That item is ‘change the damn battery’. Easier said than done. First of all, you can’t go about and be bossy and project-managerish about things. Remember, you’re agile, and the only team member. You’re the one to do the work, and congratulate yourself afterwards.
Sprint 1: we commit that at the end of the sprint, the thing is done. I know that we over-committed (we want to do the whole project in one sprint? That’s stupid!). We remember the definition of done: the item is implemented, unit tested, documented, then we do integration testing and a demo at the end. Now we can proceed. We have three work items:
- Remove the broken battery
- Connect the new battery
- Test it.
Now, remember that you need to have the proper tools. Since you’re the client, you’ll allow a small delay for getting the right tools. You’re gracious, why not? You can do it. Nobody will notice, and the budget is already wasted on the necessary materials: the new battery and the can of beer (remember the amount, this is how underestimation looks like). I don’t usually drink beer, but since this is a special occasion, I sacrifice for the team.
Before you start, you have to complain (as a developer) that you have to do all the hard work. Complain to everyone. Rejoice in complaints. Have the following dialogue:
(19:11:12) mitel: plumber level 2 mana 48 damage 15 health 100
(19:11:13) Me: 🙂 Plumber level -1 stack overflow
Now that morale is low you can start working. Remember, low morale is not an impediment, but a mere inconvenience and a necessity. SCRUM leaves no room for enthusiasm, otherwise we’d have special tasks for it.
Now, after you identified the proper tools (a hammer is always useful, unfortunately it won’t be very helpful here) we start working.
Task 1. Remove the previous battery. The simplest of the lot, and we have to do it the first, because it blocks the team! I sacrifice for the team, sip on mouth of beer, and start unscrewing some things. (note: I will call the things I don’t know ‘things’. That’s because I don’t know what they are, and they are things to me).
Remember the first time you opened a computer? Remember how you were sweating because you were so afraid you’ll ruin stuff? That’s how it should feel the first time you feel water jumping out of the half-opened battery. Run. Run for your life. Hide behind a towel, and search for the faucet that you didn’t close just right. Pry it until no water will drip from the plumbing. It is doable. Bad news: there’s no API for it, only brute force will work.
Soon enough, the battery is disconnected. Notice the water dripping from the battery. That’s where bacteria and other harmful stuff gather to have parties before you take your shower. And the reason you want to let the water run for a few seconds before showering. Rejoice.
Task 2. Connect the new battery. Now, remember, testing is blocked because the only battery left for testing is the broken one. Your testing department can try stupid things like blowing through the hose-holes, but it’s as useless as beating a dead horse. But hey, this is SCRUM! You remember you should’ve tested the new battery like that, you blow a bit in it, and you consider it works. (that was unit testing, ok?)
Remember the analogy with the computer? Where you connect things? Well, this doesn’t work like that. The hardware is not broken, but it needs pure force to be connected. Now, you have some pieces left from the install kit, that should replace some old ones, but the solution seems right to you. You don’t want to ruin the previous plumbing, that would mean that you’ll risk being forced to fix the whole plumbing, and that’s not what you want: it’s like being forced to rewrite your whole operating system. To draw a Hello World text in a window. A big no no. So you might expect that some things remain on the outside.
Pry the things closed, as tight as possible. Rejoice. Finish beer. Rejoice. Now testing dept. is no longer blocked.
Task 3: Test. You’re running low on resources (beer and time) so you decide to turn on the faucet. Notice the water exploding through your battery. See your bathroom walls getting wet. Very wet. This was not supposed to happen. Report bug. Remember, this is an iterative process, and we need a new sprint to fix this bug.
Unfortunately, we didn’t plan wisely, and we’re out of resources (mainly, beer). Supplement from the programmer’s resources with a can of coke. Analyse what went wrong and what went right. Everything was right – with great skill, the programmer implemented the battery connection and the testing department wonderfully caught the bug. Everyone did their job. Rejoice.
Sprint 2: Severely undermanned, you will have to work overtime to fix this. Forget about the plan. Panic. Yell around like an idiot. Notice that team speed is zero. Exchange jokes on the matter with internet friends. Analyse the issue. Exclaim: “So this is what these rubber thingies are for!!!!”. Thank Goodness for not starting to chew on them or even worse, for not throwing them away. Disconnect old battery. Place rubber thingies. Re-connect battery. Close the connection things tighter. Drink can of Coke. Rejoice. Remember the dangers of over-committing and remind yourself that you should always ask DOUBLE the number of beers you estimate you’ll need.
Test. Turn on both faucets, close the shower faucet. It works. Rejoice. Start wiping the floor and the walls. Wash the bathroom carpets. Throw previous broken faucet. Monitor for 7 days.
And because in the definition of done we have documentation, well… here it is.
Congratulations! You learnt how iterative development processes work!!!