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.