Always Think Things Through

Every time I think I have a brilliant idea I stop and think about any possible unforeseen consequences before I continue. Why? Well, I remember back to when I was growing up and had a brilliant idea (I was full of them) and my parents we good enough to let me “experiment” with my ideas. This particular brilliant idea was about me making a chocolate soda…

Chocolate soda seems like such a simple concept, doesn’t it? After all, it’s just chocolate and carbonated water… So I took a small bottle of club soda, took a sip to make space, and then filled the bottle back up with Hershey’s syrup and sealed the cap. What’s the best way to mix liquids in a bottle? I hope you said “shake it”, because that’s exactly what I did. Let’s just say that when I opened the bottle to take a drink the outcome wasn’t quite what I was expecting. A change of clothes and a cleaned up kitchen later, I had learned a valuable lesson; think things through a little more before starting to work on a great idea.

If you stop and think about it, it’s really not all that different from Test Driven Development (TDD). You know what you want the code to do, so you write a few tests, then you write to code to make the tests pass. As you write your code you see a few edge case scenarios, so you write tests for those. Then you work on making all your tests pass. It’s about thinking through all the steps as you go.

Granted, in true TDD fashion, I should have first verified that I could open a bottle of club soda, then taken another bottle and vigorously shake it like I was mixing something in it and open it… Of course, during that test I would have only sprayed club soda everywhere, but that would have avoided the chocolate disaster, right?

At least I wasn’t building a bridge…

From Test Driven Development across Java, JavaScript, and Perl by Aaron Cohen

There’s plenty of options for writing and running tests, so there’s no excuse for not finding an option that works for your project and the programming language(s) involved . The bigger item is making sure that they’re actually written and used. Then your developers are thinking things through and you might actually catch an issue before it goes in to production, even if it takes a while.

I’m not saying that would have saved me from spraying home made chocolate soda all over my parents’ kitchen though, after all, I didn’t know about TDD back then…

Hot Cross Buns as Acceptance Criteria

You’re probably thinking to yourself right now, “Great, he’s about to give us another recipe example for breaking down tasks and achieving the desired acceptance criteria.” Well, stop that. The food is merely a vehicle for this post.

First, a little background: I’m currently on a business trip, and as my hotel room has a kitchenette I did a little shopping at the grocery store; a Publix to be precise. Why Publix you ask? Well, we don’t have those in our neck of the woods, so it’s something different for me. After all, I can go to Kroger’s any time I want. Back home, all the neighbors have been asking my wife where I’m travelling and what I’m doing (they do the same to me when she travels for work). During the course of one of these conversations a neighbor brings up that there’s no good store-bought hot cross buns where we live, and that the best ones he’s ever had were from Publix. After all this, my wife texts me:

Publix Market has the best hot cross buns… Do I need to bring some home? You’d make [our neighbor] happy. I’ll head there tonight for some. LOL

Now, stop and read that again. This time, read it as a product owner and an engineer. The hot cross buns here are almost a feature request, but not quite. It could be a preliminary fact-finding discussion to see how feasible it was to achieve an objective; getting hot cross buns. Or maybe it’s just a discussion over some cool feature that was seen elsewhere that the product owner just wanted to share. Usually it’s something like “checkout this cool slide show transition.” This time it’s just a statement of where to get the best hot cross buns.

It just so happens that I’m in a position to find and obtain these incredible edibles. Being the engineer that I am I immediately see this as a problem that needs solving, and offer a solution: I’ll get some and bring them home from the trip. It’s not so different from, “You like that slide show transition? Let me see if I can slide that in to the sprint for you. Don’t worry about a ticket…” Nowhere in the text conversation did my product owner ask for hot cross buns. We had a phone conversation afterwards, and the conversation continued, and I said that I would stop and get a box. I figured I’d pick them up after dinner on my way back to the hotel.  Note: my product owner neither confirmed nor negated this suggestion. In fact, I think she may have been working on another project.

Off I go to dinner (I’m starting work on the slide show, and said that I’d add the undocumented, un-asked-for transition). The restaurant I went to (recommended by coworkers) had an hour wait, and being the hungry engineer that I was I passed and went next door since it had empty tables. Of course, with my engineer’s luck, it was a bakery. And wouldn’t you know, they had hot cross buns… Now, these aren’t the ones that would satisfy my acceptance criteria. They’re not Publix hot cross buns. But, being the engineer who always wants to please, and always wants to deliver more, I eye those hot cross buns. Of course, I still want to do the right thing, so what do I do, I contact a product owner. I text the neighbor. Not the product owner I had the initial discussion with, but now a totally different one! I chose to ask a different product owner on my own, not because the original product owner was unavailable or had passed me off to a new one – or was out of the office and designated a replacement. Now I’ve made promises to two different product owners (my wife and neighbor), for two different acceptance criteria (Publix and bakery hot cross buns), and still no official request within my sprint (dinner time/business trip). But I’m the engineer, I’m supposed to say how things get implemented, whereas the product owner gets to tell me what gets implemented. I decide to treat the purchase of the baked goods as a how, not the baked goods themselves being the what, and I buy some from the bakery. Better still, I don’t buy just one, but three boxes of hot cross buns. After all, if I were programming those transitions, then three unasked for transitions and some other features would be better and make my product owner happier than the one discussed, but still unasked for transition I offered to do. Right?

Guess what? My product owner wasn’t very happy when I told her what I had done. Where my engineer mind thought I was going above and beyond, in reality I was adding my own scope creep, wasting time and money on something that wasn’t asked for. If this was development, I would have put my sprint and deliverables in jeopardy, and wasted the company’s money on my salary for doing things I wasn’t tasked to do. I still put my deliverable in jeopardy, as these aren’t Publix hot cross buns, but fresh bakery ones, which won’t last nearly as long.

Plus, since the Hot Cross Buns were not in the original sprint plan (business trip), I have circumvented a process that is in place for a reason.  Remember that as a developer, the process is there to protect you too, but if you start agreeing to do things outside the process and without documentation, you could find yourself in a lot more trouble than you initially bargained for.  Plus, there’s always the “but you did it for me with the Hot Cross Buns…. Why can’t you do it for me with the Coffee?” argument that the product owner can make.  Or the you did it for product owner 1, but you won’t do it for me…. argument (which could get you into all sorts of HR issues.)

So the next time you want to do a favor for your product owner, make sure to agree to what is being requested, then prioritize the work, and document it. Don’t go assuming that they want something just because of a conversation or email. Don’t go involving other/different product owners with your questions because you’ll only get conflicting marching orders, and acceptance criteria. If you think there’s a better way of doing something, discuss it with the original product owner, as there may be a reason they are specifically asking for something, and there’s no need to add in all the extra work you’re considering. Instead make suggestions on how to improve upon their improvement.  And finally – Just remember the hot cross buns, and your product owner won’t get cross with you when you deliver.

As for all those hot cross buns? It looks like I have a lot more breakfast items than I had planned for…