This quote was originally used by Christopher Daily in this post. The quote seems to be self-explanatory.
I was on my way back to the US from Bangalore, and there is a sentence that keeps banging around in my head. The sentence is as follows: “An idiot with a tool is still an idiot!” If someone else has already been quoted on this, I will gladly give them credit.
Regardless of whether it is an original thought or not, it paralels across our personal and corporate lives. I can’t tell you the number of times I have bought some gadget or software that I thought was cool, but wasn’t sure how I was going to use it. I have tools that I don’t know how to use. Having a tablesaw or a router does not make me a carpenter.
How many of us have bought treadmills and other exercie equipment thinking it would help us lose weight? Yet did we bother to change our lifestyle? Did we cut back on cookies, potato chips, and McDonalds? Just because you have exercise equipment does not make you a personal trainer.
We buy self help books telling us how to deal with difficult bosses, how to budget our way to a million dollars, and how to succeed in management. Unless we make changes in ourselves, we will never achieve our original goals. We are an idiot with a tool.
Corporations are much the same way. We buy software products from vendors like Salesforce.com, Microsoft, Oracle, and IBM to name a few. The vendors tell us that there latest/greatest tool will be the silver bullet the customer is looking for, making the company lots of money, and our worklives better. What most of us fail to realize is that, to achieve those benefits, we need to change our culture. We may need to change our team, department, or even corporate culture. Every corporation has a virtual boneyard of stuff they have purchased based on someone’s recommendation that ends up not being accepted by the company. Even worse are those tools and processes that get implemented without much thought for what has to change and end up costing more than the original benefits. How many projects start off with someone saying “This software doesn’t do what we need. We need to make changes”?
Tools (software and processes) don’t solve problems. People solve problems. Tools merely speed up the change. Don’t buy the tool unless you know how to invoke the change to get it accepted.
Thanks for coming in today.
I have spoken about excellence a couple of times over the last year. (click here and here). Technical excellence should be a requirement for development organizations. Seems simple enough. Pretty straight forward. After all, we are in the business of developing software, aren’t we?
Yet, this doesn’t seem to be at the top of the priority list. We seem to take short cuts. Somebody always has a time-to-market issue.
The ROI is tough to prove. By itself, being technically excellent doesn’t drive income to the bottom line straight away, yet lack of technical excellence will drag your bottom line down. Here are some excuses I have heard:
- The business is beating on us for more functionality faster.
- The sales guys have already over-committed us by signing the contract for the date and scope to be delivered to a client. Development will find out after the fact.
- We don’t have time to automate our deployment process. We need to start coding.
- Automated testing doesn’t work for us. Our testers can do it faster.
- The users have changed requirements again, causing developers to rework their code again.
Often, these time to market (I call them BS) factors often cost up to 10X the original cost to develop. Yet, we find out the cost later. Those enhancements that “had” to be there for a client will cost us 10X to modify later. Most of us hope we are not going to be there to feel the pain, having moved on to a new career inside or outside our employer.
Let’s look at this a different way. Your plumber tells you he can patch a leak quickly for $60, or he can take replace the pipe for $100. Most of us would say “Do it right. I will pay the $100.” We won’t be happy about spending a $100, but it is the right thing to do. The plumber doesn’t even have to mention that the patch is temporary, and we will probably spend more money later.
So, why is it that we have a tough time with being technically excellent? Regardless of whether you are drinking the Scrum Kool-Aid or not, your development organization has to be technically excellent. Take the time to do it the right way. Refactor the gobbledy gook code. How can you afford not to be? I am reminded of the quote: “You can pay me now or you can pay me later!”. In the case of software, you pay 10X.
Before I go…………… Ok, so I am coming across a little strong to make my point. Corners can be cut as long as they get corrected in the very near future.
Thanks for coming in today.
Given the struggles I had in English at Ball State, I never thought I would say this. I miss writing. It has been a while since I wrote a post, so I am not sure anybody will see this one. It’s ok if there isn’t anybody out there. Since joining Fidelity National Financial (FNF), I have been sporadic at best getting anything posted. The challenge for me is not writing, but what to write about that won’t reflect on FNF. Working for FNF, most of the good/bad experiences that motivate me to write occur in the corporate environment. As a manager in the company, that puts me in a hard spot. How do I offer opinions and share examples?
Whether anybody actually reads this or not, I find it therapeutic. I will just have to find a way.
Thanks for coming in today.