Saturday, October 23, 2010

Not all battles need battleships

Working in an “Agile” development environment (and use this term very loosely so don’t shoot me yet); I’ve seen many hilarious and yet seriously inefficient examples where using the latest technology and programming techniques have had no match for common sense, good judgement, and the right use of tools for the just the right tasks.

This short story is about one developer I worked with that really opened my eyes to how bad “tunnel vision sickness” affects the outcome of a task.

For numerous reasons, let’s name this developer “Bob”.

One morning, I walked over to Bob’s desk and showed him a webpage that our client wanted to get a pulldown menu from, to use on his own website. I told Bob that I nor the client did not have access nor would have the kind of data (values) that pulldown menu has, but that we would like to use that data nonetheless as it was relevant to what the client’s website was… and we didn’t want to reinvent the wheel.

Bob and I sat and looked at the page and I asked him, “so how would you suggest we get that data, and put in into our database so we can then create a pulldown menu on our client’s website, populating data from that new table.”

Bob quickly said: “Oh that’s easy, I’ll just create a script to read that page, grab that pulldown menu using the label of the select field and save the values directly in a table that I will create in our client’s database.”

I said: “Wow! That’s neat. How much time would that take? Considering this pulldown menu is almost 1000 rows long.”

Bob says: “Well, let’s say around 1.5 hours. And I still have to test the thing to make sure it works when I do start pulling data off that page.”

Then I say: “Oops, isn’t that a bit too long for a script that does just that? Besides, this is a one-off task and we wouldn’t be using that script for anything else than this page we’re copying the data from anyway. And I need the data in the client’s table in time for lunch.”

Bob pauses for a few minutes, scribbles on his notepad, then says: “Nah, it’s a really nice script that we can use for future tasks that we need to quickly copy pulldown menu values from some page to put directly in our client sites. Besides, I can modify the script so that I can easily replace the select field and add a auto-create table function so I don’t have to manually create the table in the client’s database. Only takes like 5 mins to update the field, then run the script and maybe a minute for the data to be in the client’s database. Why?”

I start becoming edgy: “Hmm… why? I guess I just said why…. The client needs the data, and I need it to be in his website in time for lunch. Maybe even sooner if I could. Can’t you find any other way of doing it faster? Like maybe 10 minutes or less? You can use any tool you wish. I mean there’s Excel, Word, maybe even PSPad to find and replace variables and put that into the database afterwards.”

Bob says: “What? Why do that? That’s manual work that will only cost us more time and we’d have to repeat it everytime in the future whenever we need to do something like this?

3 minutes into the conversation, I put my foot down and ask Bob to come into my office: “Ok, here’s the deal, I asked you to do that task to try and avoid using too much time and see if you’d find a quicker way to do things. But I need to show you something here…”

In my office, I open up a Firefox window, open the page I wanted to copy the pulldown menu from, I right-clicked the Inspect Element using Firebug, right-clicked the select field in question and clicked COPY, then I opened Word and pasted the thing. The HTML of the pulldown all pasted into Word and sprawled like gibberish. Bob smirked. I let him be.

I then hit CTRL+H and found all the field delimiters (select, values, etc) and replaced them when commas and carriage-return after each line. All in all I used up to CTRL+H combos. J Bob still didn’t get what I was doing 30 seconds into my demo.

I then opened up the database, created the table I wanted, then opened up an SQL box and started typing an insert statement, then a copied and pasted the now seemingly harmless bunch of Words I had in word, into the SQL box and closed it with an execute command then hit enter.

Then I took my phone which I already set to timer before I even went to Bob, and stopped the watch and said: “8 minutes Bob, and that’s including our little talk.”

He exclaims that he didn’t understand that THAT was the only thing I actually wanted him to do. And even gives me a follow-up statement saying: “… but why did you have to ask me to do that in the first place when talking to me and going back and doing it yourself cost even less than the time you initially wanted me to do it in the first place?!”

I tell him: “This is exactly why I asked you to do it. And this is also why I needed show you. I understand that you do great things with the technology that you develop, and you are well armed in what you do. But not all battles need battleships to be won.”

The moral of the story here is that WE developers (and I say “we” as I was also once a programmer myself and I had my fair share of “tunnel vision” and “railroad programming”) should realize that there are much easier and faster ways to do things without breaking the bank and stressing yourself out under a pre-set timeframe to finish something you’re asked to do…. and still get the results exactly the way the requestor wanted it.

I don’t program code as much as I used to, but I still know how hard it also is to develop software code by code, hence… relax, spend a second or two thinking of alternative instead of locking on to the idea that comes first into your head. It does not hurt to think out of the box!

Suffice to say, Bob’s not with us anymore, and he won’t be stressed with my constantly probing why it took this long to do something. But I sure do hope that I don’t get too many “Bobs” in my career, and the ones that I do get, I hope learns a little something from this experience.