Over years of my development career, I have come across IT professionals who always over estimate themselves and under estimate the work that they’re doing. Such behavior creates giant issues for companies and clients, who always end up saying “the project will never be done” after months or even years of frustrations. I picked 10 most irresponsible statements and listed them in this blog post. Don’t get me wrong. This is not against anyone of you. I made some of these statements myself years ago as well. But I have learned lessons the hard way from the ramifications. I’m sharing my experience with you in the hope that nobody will repeat the mistakes.
10. "I'm pretty sure we can do it. We just need some research"
No you can’t do it. Otherwise why do you need any research? Why would you talk about something that you don’t even know?
9. "The coding is done but I haven't tested it yet.”
Total deception for the product owners. You think they don’t know anything about technology?
8. "It's just a configuration change."
How about “It’s a configuration change” (without the “just”)? Did it ever occur to you that your code stopped working “ridiculously” after that configuration change?
7. "It's just a web service call."
How about “It’s a web service call” (without the “just”). Are you handling the NULL values returned by that web service by any chance?
6. "It should work. “
Where did you get the “should” from? Have you tested it?
5. “We have to do it this way because it’s cool new technology.”
No you don’t have to. Does you boss have enough budget for the cool technology? Can your client wait two months for you to get up to speed on the new cool stuff? The business we are in is a battlefield and not a playground.
4. “The system has to be designed in such a way that it can work with all the other systems.”
Ideally yes. But have you seen all the other systems yet? Why don’t we build something that works first? Again look at your boss’s budget and your own deadline.
3. “Let’s hard code this value for now. We will make it configurable later.”
Guess what? I never got a chance to change a value I hard coded two years ago.
2. “I’m looking at the bigger picture and you are not”.
Rule #1: Never underestimate your teammates. Your “bigger picture” can be dangerously perceptional.
1. “Don’t call me over engineering. I’m designing something that is going to work not only this time but also 5 years down the road.”
Counting the CPU clock before having a working system is pointless. Yes you ARE over engineering.