tags:

views:

649

answers:

11

Have you ever played the "tech card" towards your project manager to gain more time for something which isn't relevant for your actual task at all?

My Task will need x more Days because [insert random tech stuff here which sounds great and believeable].

I recently did this "for the good" (imo), refactoring some core parts of the main application to gain more performance.

EDIT: To clarify, i am certainly not doing this all the time. Just wanted to hear some (honest, not ideologic or theroretic) opinions :)

+12  A: 

Why didn't you just asked "I need to refactor some core parts to increase performance, can you fit some time in my schedule for it? The app will be shiny after that!"

Better say the truth than lying. And for performance i see only gains in it.

fmsf
+1 for "shiny"
Joachim Sauer
I agree. If you are met with a "no" then use this as an opportunity to educate your PM about why "shininess" is important. Having a PM who gets it will make your life easier and next time you feel the need to pad your time estimates he or she will already be in your corner.
Tina Orooji
The best part of the honest approach is that if you receive a "no" and app performance suffers for it, management is more likely to say "yes" next time.
Ben Blank
+9  A: 

No, never.

I have given real descriptions of issues and solutions if I need time for them.

Most programmers have a job because they work for a business; programming time costs a business money. There should be good business reason, which you should be able to justify, if you need the time or resources to do something that you think is necessary.

DanSingerman
Ehm... Most (all in fact) software businesses exist because there are programmers who work for them; the company's assets are generated by the time spent programming. There should be a good reason, with a clear justification, for not allocating the time or resources for them to do something that they think is necessary.
Felixyz
+17  A: 

This damages your reputation to some degree and risks losing it altogether for the assumption that you genuinely know best in a situation where you probably don't have all the facts.

If your internal cost/benefit still says to run with it, then good luck to you. Me, I'd rather be strongly opinioned and up-front about things like this, but I can't say I've never had to do it.

annakata
You certainly have a point with your first sentence. Didn't think of it this way, thank you.
Karsten
+1. Honesty is the best policy.
Matt Ball
+14  A: 

Real life is not Dilbert.

Matt Olenik
not far from it either :)
JohnIdol
+2  A: 

Just tell the truth. Although your fib is innocent, it may taint your reputation. If your project manager doesn't give you time to refactor your code, perhaps there are more important things (in his/her opinion) or you didn't communicate the benefits of your refactoring well enough.

Erik Ahlswede
+4  A: 

When I was much younger and a lot less experienced, yes. Not for the greater good mind you, just general laziness. Having worked for myself for the last sixteen years it is no longer an option.

Now if the real question is 'is this an advisable tactic' the answer would be 'probably not'. You should have time to do a good job, and if not, you need to sit down with your manager and explain the risks and deferred future costs of not doing the job properly. If they don't buy it, let them face the consequences having been aquainted with the facts. You are also giving reasons that your manager can pass up the line, as to why a project shouldn't be progressed, and you might need to know the larger implications of your actions. e.g. Missed release dates might have substantial sales and marketting implications; perhaps your refactoring would be better scheduled post-release to improve the quality of the code base for a successive release.

Shane MacLaughlin
+3  A: 

Yep, be honest at all times. Lying is OK when you're 8 and took three biscuits when you were only allowed two, but as you grow up, you realise it harms others, as well as yourself.

Business is about making money, and choosing the best solutions. Just make a good case for the extra work, and make sure the negatives of not doing the extra work are clear. After that, practice detachment: if they want to shoot themselves in the foot, that's their business. If you're right, they'll come to you when they realise their way didn't work. If not, at least you were reasonable and professional about what you believed.

Lee B
+1, what I was trying to say, but better.
DanSingerman
I've gotten worse. I take all the biscuits nowadays :(
willcodejavaforfood
+2  A: 

I understand why you might do that. But why simply not saying:

"Feature ABC will take 10 days because I really recommend refactoring XYZ before implementing it."

Instead of

"Feature ABC will take 10 days because [insert some believable but completely bogus reason]"

Sergio Acosta
My guess would be that the former might not been seen as a necessity to complete a release whereas the latter might. It's a dangerous game to play for sure, and probably not a wise course of action.
Shane MacLaughlin
A: 

If you have failed to meet a deadline, its your problem. You have listed no crazy constraints, no special circumstances and it seems that your seeking advice to make your apathy (or inability to focus) a problem that your company must solve while coddling you in hopes that you do not resign.

Code it, test it, do it or get out of the goddamn way. I saw your edit, why else would you be asking this? Either you want SO reputation or an easy way out of an uncomfortable meeting.

-1 .. tasks related to your skill are up to your project manager. If you can't do it, say so. If you don't feel that the task is agreeable with the skills on your resume, you are admitting that you have learned nothing since being hired. If your not being paid enough, speak up. Why, oh why would you consider putting every job on your team in peril? Are jobs so easy to find? Why even debate the hypothetical?

So, which is it? You have listed no circumstance that should elicit any kind of special sympathy.

Edit:

This is the response you are likely to receive if your card flips over while playing it.. depending on how smart management is. If management is that terminally stupid, its time to find a new job. I don't want to seam heartless, I'm just a guy who funds a small dev shop out of pocket without angel investors.

Tim Post
Honest reply, thank you. Having to deal with a non-technical project manager, this was the easiest way for me to use two days for an improvement which in my opinion was needed badly, but "fighting" for it would have taken a week at least.No, I'm not in trouble ;)
Karsten
Glad to see you not in trouble, but why think of this?
Tim Post
I might add my reply is not heartless, but one you might encounter.
Tim Post
+2  A: 

No, I believe that just adds more fog to the issue at hand, next thing you know the manager is talking to another developer and he has no idea why you needed extra time since that tech thing you talked about is not even in the project.

If you can't be straight forward with your boss as to why you want more time, you should not be working there. Your boss knows what needs to get done and when and how much it can cost, just because you want to re-factor something does not mean that the time and the money exist for it to happen.

X-Istence
A: 

Be honest, keep your integrity. Not because lying can damage your carrier, but because integrity will keep you at piece with yourself.

Whilst making profit is a bottom line of any business; it is just a bottom line. Drug trade and racketeering bring profit alright. And people who stay away from these activities barely because they’re illegal don’t quite understand what the law is all about. Good business is much more than profit, which is just a bottom line.

So is quality software is much more than functional adherence to the spec, the functional part is just a bottom line.

This is to say, that it is ok for a programmer to spend time on aspects of software that might be very difficult to justify in terms of immediate tangible business benefits (after all the business itself is not all about tangible benefits!). But willingly leaving these intangible or hard to quantify aspects out is willingly taking quality out of the application.

You don’t need to provide a separate justification either, some rework and iterations should have been in the initial estimate, they are natural part of the task. And you don’t have to worry about being perceived as a “slower” programmer, I find that the better developer I personally become the more quality I can put into a new software feature given the same task duration. Just focus on the task, cut procrastination, e-mails and water-cooler talk and put this time into quality. It leaves a very rewarding feeling then you leave your desk in the evening.

Once your work will get renowned for its quality there going to be no questions about the estimates you provide.

Totophil