Geeks With Blogs
Frank Wang's inspirations on .NET
IEnumerable<Inspiration> inspirations = from i in DataContext.Inspirations where i.Sharable == true select i

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.

Posted on Wednesday, October 15, 2008 8:00 PM Misc. | Back to top


Comments on this post: 10 things a professional developer should never say

# re: 10 things a professional developer should never say
Requesting Gravatar...
How true!
I meet a lot of professionals around who state the same, atleast once a day. Many a times, due to pressure from the client, even I have been made to state the same.

I feel all this is part and parcel of the IT industry.
Left by Pradeep on Oct 16, 2008 9:01 PM

# re: 10 things a professional developer should never say
Requesting Gravatar...
I disagree with some of your statements. Sure when you're talking about large enterprise applications, then these are all largely true, but for low impact, limited projects where the developer has intimate knowlegde of the detailed workings of the application, there is certainly room to make statements such as "it's just a configuration change" especially if the program is well designed to handle said changes...

Number 4 is another point that I disagree with given certain circumstances. Building a program "that just works" translates to "building a shoddy half-baked program that will require more maintenance and patching as time goes on". I feel that it is much better to spend the time up front and design the program to meet the needs of the business (given the scope of the request) and anticipate possible future requests so that you design your application in such a way that it can be modified more easily later. I can't tell you how many hours (years) I've wasted changing poorly written programs, and never been able to rewrite due to lack of time. If it's not done right the first time, then you'll never get a chance to go back and do it right later given the state of time and resource availability in modern IT units - you'll be patching that garbage forever. Some might call it job security, I call it wasting precious resources that could be developing new, revenue-generating, products.

Now for what I agree on: #3...

Basically, I think you're venting here and really haven't put much thought into this list. Just sayin'.
Left by Will on Oct 21, 2010 10:54 AM

Your comment:
 (will show your gravatar)


Copyright © Frank Wang | Powered by: GeeksWithBlogs.net