188

A few months back I took over a job from someone who was quitting for the same reasons I am here today. The job involved developing an in-house application that would be used mostly by the staff. The person abandoning the project was not even close to finishing the application but got sick and tired from stress, extreme deadlines, etc. At the time it seemed like a great opportunity. I have a lot more experience than the previous dev and the project didn't look that hard to complete, so I took the project.

The meetings went great; people listened to my advice. We made big leaps in quite a short time. Bugs were fixed, the UI got an overhaul, a lot of the code got refactored with re-usability in mind. The application finally started to look and work like something.

After a while, new features were requested, planned and executed. As the time went on, the manager kept posting new features requests that he wanted to be done in an extremely short period. For example a fully featured, production ready fleet management system in 14 days, starting from scratch.

NOTE: The manager has little to no technical background.

This came with the consequences that either I deliver poorly written and untested code, or that I don't make the predefined deadlines. Two horrible situations IMO.

I tried to point this out during meetings, but it was waved off with reasons like: "The end user does not see the tests, as long as it works and looks good it's fine, time to market is more important." And the last reason, the one I hate the most was, "Such a smart developer like you, has to be able to do that in x amount of time."

How could I make clear that a production ready application or features are not built in a short amount of time? That a prototype is not the finished product, and that code coverage, testing, releasing betas, etc. is extremely important to deliver quality?

  • 11
  • 70
    Have you tried turning the "such a smart developer as you" remark around by using those credentials and you're experience to explain why these deadlines are impossible? In other words, what have you actually tried before that had no effect? – Lilienthal Jul 26 '18 at 14:15
  • 23
    Have you pointed out that this why the last dev quit? Or, I guess, in general, what (if anything) have you actually said to your boss about his unreasonable deadlines? – HopelessN00b Jul 26 '18 at 17:06
  • 3
    @Lilienthal I actually tried that, it worked for like 5 minutes. The last things I tried was, going for a lunch with him to try to explain how software development actually worked. What requirements have to be met before going to production, with some well-known, relatively simple, applications as an example. This got waived away as unimportant, this is not how we work. – Odyssee Jul 27 '18 at 13:22
  • 5
    @Odysee Oof, you have my sympathies then. Consider adding that comment to your post, though I guess you've got plenty of input already and have decided what your next steps are. – Lilienthal Jul 27 '18 at 14:44

12 Answers 12

310

A lot of good advice here but I'll add my 2 cents

Never negotiate the Price, Negotiate the Features

Time is your currency and your budget is low. Here's a sample script (manager goes first):

- I want it now
- OK. What are the features?
- A, B and C.
- In that timeframe I can only do one. Which one is the most important?
- A smart guy like you can do all of them
- A smart guy like me knows his limits. A smart manager like you should listen to his experts. Which feature is the most important?

If written as an equation, it's the same as arguing for more time for all features, but breaking it down to pieces is better because:

  • It gives your manager client agency. Instead of getting pushback, he gets to choose which one is the most important feature
  • You get to renegotiate it at every iteration. This gives you a lot of leeway if something takes longer than you thought
  • You're effectively doing sprints but your client doesn't know, because it's abstracted from him. More on that later

A smart guy like you can do faster

Instead of getting upset, try something like this:

A good manager like you should know to trust his experts when they tell him something cannot be done.

Try that on for size, see how it goes.

A good few comments mentioned the above phrasing might be too abrasive to use with a superior. I believe it can be beneficial to the relationship when delivered with the right tone, but I certainly concede their point. I present a few suggestions below for those with varying mileages:

Many people might see "a X like you can / should ..." as manipulative (since you're using a cheap complement to get them to do what you want) and a borderline-insult (since you're implying that if they don't do it, they're a bad manager) - I would recommend avoiding that, or phrasing it differently, even if the manager did that first (they are still the superior, after all)

by Dukeling

and

I’d change “A good manager like you should know to trust his experts” to “A good manager like you knows to trust his experts”. Instead of wagging your finger (“you should know better”) you’re imparting on them a quality they will want to live up to.

by user137369

Don't mention testing

This is something your manager thinks he should have an input in, but it isn't. Testing is done by an expert. You're the expert. You're also the one who will work on the project in the future.

Testing stores currency for the future. You put 2 weeks in the testing piggy bank, and when you run short of time in the future, the magic faery will have put another 2 weeks for you to find.

Never say "it's done but needs testing". If it needs testing, it's not done. You're not working on testing feature X, you're working on feature X.

One semantic trick for "testing"-averse managers is to use the term "stabilizing" instead

by BobRodes

Your Manager is Your Client

If he's not technical you don't speak the same language. There are things that need to be abstracted for him. What these things are is up to you to figure out, because you're the expert in the room (cough *testing* cough). Your manager needs to be managed as any client is, and it's part of your job to do that.

Document Meetings

At the end of every meeting, write down everything you talked about and send it to your manager. This helps create a roadmap and will act as excellent CYA material should you ever need it.

  • 46
    Many people might see "a X like you can / should ..." as manipulative (since you're using a cheap complement to get them to do what you want) and a borderline-insult (since you're implying that if they don't do it, they're a bad manager) - I would recommend avoiding that, or phrasing it differently, even if the manager did that first (they are still the superior, after all). – Dukeling Jul 27 '18 at 1:04
  • 19
    I’d change “A good manager like you should know to trust his experts” to “A good manager like you knows to trust his experts”. Instead of wagging your finger (“you should know better”) you’re imparting on them a quality they will want to live up to. People try to live up to their labels. – user137369 Jul 28 '18 at 11:39
  • 3
    Never use a same strategy (like "a good X like you") your boss!. Never. Just say: "No, i can't do, it is impossible". – Brethlosze Jul 29 '18 at 14:14
  • 4
    One semantic trick for "testing"-averse managers is to use the term "stabilizing" instead. – BobRodes Jul 30 '18 at 6:28
  • 1
    @hyprfrcb Saying no can quickly be interpreted as "I won't"/"I don't want to". I've always been told/taught to come up with solutions instead of problems. – rubenvb Jul 30 '18 at 9:15
62

NOTE: The manager has little to no technical background.

So this manager, presumably, had time to develop a technical background but has not done so. Why? He either is uninterested or unable. Keep that in mind going forward.

"I need a fleet system in 14 days".

I am sorry boss, but it will take 28 days. That is the soonest I can deliver.

There is no need, and it is self defeating to explain the software development process to such a manager. Your estimates will need to include the "tax" of testing, deployment, and bug fixes. Just include it in your development time.

When you are done coding such a system, but it is still untested, tell him that it is not done.

However, a better approach would be more of an agile type thing where you implement and test some features, and put that before him. That way he sees something.

You could further break down the schedule such like:

  • Initial Application: 8 days
  • Provisioning Feature: 3 days
  • Tracking Feature: 5 days
  • Auto-renew feature: 7 days

By doing something like that you can probably get away with a much longer schedule than you would by just quoting the whole project. The manager is satisfied as he will see something in 8 days rather than the 14 he was wanting. It does not matter that there are no real features. Do not breakout that the initial app will need to have a web application built, a database designed, etc... he just does not care.

From the brief information in your question this does seem like a terrific opportunity. You are getting to lead your project and can no work on your project engineer skills. Also you will be developing your skills at negotiating technical ideas to the untechnical. This is all very valuable experience. Good luck.

50

You say "I've never left a project unfinished before." It is time to start.

Every professional will quit a job at some point when the client is unreasonable. There are bosses and clients that can not be satisfied and have to be fired. When I am willing to quit and walk out the door, I am far stronger in any meetings or negotiation.

Having worked on a fleet management system, there is absolutely no way to deliver one in 14 days. It is almost impossible to define the problem in 14 days let alone solve it.

10

This is not general advice for *every* IT project out there; it is specifically for this situation, in which a seemingly impossible task is set by a management that doesn't want to listen (or can't), also when you just don't want to quit immediately. Obviously keep working the "interpersonal" angles to find a proper solution to the core problems.

I've been in such situations. On a technical level, the path is clear: solid, modern development practices - agile, BDD/TDD, automation. That means:

  • Tests are written before the code, interleaving a single test, and the code to make this test green. Feel free to start out with integration tests instead of unit tests. They will become cumbersome at some point in time (due to being slower to execute the whole test suite) but are great to get going quickly.
  • No code is written except the minimum which turns a red test green.
  • The test is your specification. If you want to hammer it home, use Cucumber. Things that are not tested are not specified, and things that are not specified are undefined behaviour.
  • Whenever there's any "tooling" type of work, auomate that immediately. E.g., your deployment. Keep it basic at the beginning, even if it's all just hardcoded server names etc., but make it automated. Time savings here are really mounting up quickly.
  • You work in some agile framework like Scrum or Kanban. If your management and company is nontechnical anyway, I'd shoot for Kanban - which simply means that you cut your work into small, well visible slices and avoid WIP as your highest priority.
  • Deliver a first working version ASAP. A whole fleet management is too much for 14 days, but you can get something out in 14 days. Anything. Even if it's just a simple web page protected by basic authentication, displaying a list of cars in the pool. Then go on from there. Do not treat this as a "prototype" or something like that, you will never have the time to start from scratch; treat it as production code from day #1.
  • Do not give overall estimates. Instead of "I need 28 days instead of 14" (which is nonsense anyways, your requirements certainly are not clear enough to even calculate the 28 days) say "Sure boss, I'll start work on it immediately. See, here's the backlog/Kanban board, do you have input on the order of things?" etc. When they ask "when are you done", answer "I can't really tell, but you see how I divided the tasks into comparable bits, we'll see in the next few days how fast work processes, OK?".
  • Get them used to the idea that you are not doing giant project plans, or that software just appears full-fledged out of nothing after 14 days. Make them aware of how a Kanban board works, maybe give them a 15 minute report every day to get them "into the boat". Your velocity will be pretty obvious, there will be no need to explain yourself as long as you show them some small incremental steps coming out every day.
  • If they come to you with deadlines, find out how to reduce the work to the barest, essential minimum; divide that into as small as possible units (which hopefully can be delivered to production individually) and just go crunching. Do not, I repeat, do not let yourself put into pressure to do 18 hour days, or something like that. It does not work. Your productivity decreases after a normal day's work, anyway. Burn-out decreases your speed incredibly.
  • Forget the idea of "finished". Software is finished when the last server is turned off. You will never have an empty backlog. The important thing is that you keep your own standards up (because you know that without them you will fail in the mid-term), and that you keep a healthy velocity that you can keep up indefinitely. Yes, these are buzzwords, but they actually have a meaning.

On a personal/IPS/human level, stay calm and keep hacking. Avoid any non-technical discussions. Don't complain, but do say if you need more resources (faster PC, more server-side nodes/RAM/HDD etc.) to speed up your development. Give them solutions for individual problems; be brave and decide how to implement stuff, or where to split tasks into smaller, deliverable units. Let the Kanban board tell them that it does not work as fast as they want, don't do that yourself.

Good luck!

9

You have two basic choices here.

  1. You code your ass off and deliver the untested result to the specified timescale. Re-assert the fact that it's largely untested and therefore there's a risk that it'll break or not fully align to the requirements because there was no time in the resource/project plan to do this.

  2. You code it properly and test as you go on. This obviously will take longer, but it will give better results.

Offer this as a choice to your manager.

Bluntly:

Do you want it done now, or do you want it done right?

And be prepared to back those choices up with time estimates (both for development and for QA) and reiterate that you can't fit both into the same estimated time.

"Both" isn't an option here in the real world. Not unless you get given more bodies to do the analysis/testing/QA.

  • The answer I was looking for - a manager has his view on business goals. If it is better for the company to present features fast (even if they are buggy and partially broken) then that can be a choice. - The important part is to communicate clearly what the tradeoffs are. But defining business goals is not the primary job of the developer. – Falco Jul 31 '18 at 10:55
  • 2
    The response will often be "I want it done now then you can improve it in the future", I'm afraid, so this approach doesn't really work. Pete's right - you shouldn't lie but you should obfuscate all the technical details away: the project's not done until it's [quietly] done right and that's that. "I want it in 14 days" "Sorry, but it will take longer than that. I estimate more like 3 months" Period. If that's not accepted, and you're backed into a corner, then you leave. – Lightness Races in Orbit Jul 31 '18 at 16:26
  • if you deliver it untested you WILL get blamed for any and all problems down the line, even if the people taking delivery accepted it and signed off on knowing that it's untested and you delivered it as such under pressure. Been there, done that, got the termination letter. – jwenting Aug 1 '18 at 10:48
9

I see several problems in the communication and understanding between you and you manager.

Why test at all?

It sounds like you presented testing as an additional work package. It is not (or should not be) additional work, but an integral part of your work. Like a construction worker cannot construct a building without making sure all walls are straight, you cannot create reliable software without tests.

Don't mention testing as a separate work package, but calculate the time of any implementation including testing. There is not one without the other.

Snap your fingers and finish up!

Your manager has obviously no understanding of how software development works. By fixing many problems in a short time, you confirmed his belief that you are a magician who pulls software out of hats.

Try explaining to him that you don't create colorful windows / pages, but code. Complicated code that is comparable with complicated instruction manuals for computers. It's not called programming language for no reason.

Like no writer can create an elaborate instruction manual, you cannot create a complicated feature in mere days.

A car fleet system is not a simple paragraph in a manual; it is a completely new manual. If your manager doesn't believe you, ask him to describe the fleet system to you, every single detail down to the place where the keys are kept for every car.

A smart guy like you can do faster

Refuse to accept any unrealistic deadlines. List the work packages you have to complete and how much time you estimate for each package, sum the times up and set your own deadline.

This might sour the mood of your manager, especially since you magically worked so fast at the beginning. Back your estimates and deadlines up with facts and lists; make them more real than the imagination of your manager.

Everything is most important

Create a prioritized ranking of all features like sticking post-it notes on a board. Every feature has a rank, and you implement them in order of their rank. If (or rather when) your manager requests new features, let him sort them into this ranked list. That makes it clear that some things have to wait until others are finished.

Still not finished???

This is my most heartfelt advice: For the love of yourself, don't let yourself burn out! You are a human being and can only work so much and so hard before you eat yourself up. Work as good and as fast as you reasonably can sustain for a prolonged time. Things that are not done in time have to wait. Make it clear to your manager that you do everything in your power, but there is no way you will satisfy his unrealistic expectations.

7

Unfortunately there is no good way to handle this that isn't going to cause you some pain.

First, cover yourself. Make sure you send your boss emails explaining that the timescales are unrealistic and that to even attempt to meet them you will have to skip proper testing. State that you feel uneasy about this and feel that it will cause various problems, such as poor quality products and technical debt. Also keep copies of all the emails you boss sends you requesting new features.

Next, start looking for a better job. Unfortunately with this kind of situation either you will have to go or your boss will have to go, and you can't really gamble on it not being you.

Finally, do what you can to meet the deadlines. If you get blamed for anything point out that you warned your boss of these problems, and that they have responsibility for not acting on them.

  • It might well be exactly what is in mind. "Do something reasonably dumb and crazy that will force him to start looking for new options. Meanwhile this plays out, we'll come up with the position he's supposed to take when his current situation crashes." – mathreadler Jul 29 '18 at 10:54
5

It is unhealthy to keep working like this. As IT professionals we can (and do) work long hours sometimes. If you've working 60-70 (or more) hours on a regular basis there is a huge problem and you will be the one to suffer for it.

My current employer understands work-life balance. Most weeks are 40 hours and then I'm done.

At my previous employer this was not the case.

We handled by getting specific requirements that had a sign-off from all stakeholders (internal and/or external) before any work was done. Project scheduling was kept in MS Project (or another project scheduling tool). Any changes from the original plan were entered into Project to determine the effect on the schedule. Changes also had to have signed approval from the stakeholders. If it was a small change an email could suffice. Anything major (such as adding a fleet management system) would require changes in documentation (business requirements, design requirements, technical specifications, etc.) before making the change.

4

You say your manager has no programming background. So programmers are a black box to him. He tells them things and sees how long they take to come up with something. He finds that if he disregards their overly pessimistic predictions, they deliver more in less time.

The solution is to provide proper feedback. There is no proportional cost for him making you suffer and squeezing his workers dry.

So first be sure to get a paper trail. Get every assignment in writing. Let him sign off on every hour you have to work overtime. Get him to sign off on your statements that code is untested. You need to cover your ass because shit is going to hit the wall and you need to have your ass covered in order to make clear that it isn't your shit.

I'd recommend checking your options of getting unionized as well. Depending on how reasonable the company hierarchy turns out, it may not be necessary, but it might come in handy for making a difference when upstairs management is apathetic or incompetent as well.

Either that or get out while you can and get somewhere where you are appreciated as a sustainable source of work rather than firewood.

4

Along with the other good answers, I have another tool for your toolbag as a dev.

Explain to your manager the following triangle:

Fast, good, or cheap: pick two

The idea here is that you/your manager picks only 2 options. There is not a "get all the options" option, as that just doesn't happen. Even small projects take time to get right, and your project isn't small.

I'm working solo on a nightmare of a Frankenstein 20+ year old app at work. I'm supposed to "fix all the things" and keep up with customer requests at the same time. Fortunately: my supervisor, boss, and bosses boss knows this isn't possible in the time frame given by even higher authorities, so I'm not going to be dragged through the mud for it. I might still get flack for this problem, but I have several people backing me up that understand the above triangle.

It sounds like you don't have that backup, so set the record straight. As other answers said, when you get "accused" of being a "a smart guy like you", fire back with:

A smart guy like me knows what's possible in the time frame you're asking for, and this isn't possible.

Make sure to say it deadpan serious. Don't smile, just make it deadly serious. If you don't capitulate or otherwise negotiate, you may come off as stubborn, but the manager can't weasel you into trying what you know to be impossible, then blame you for his mistakes. I've done about every variety of other tactic, and this seems to be the only one that doesn't persistently backfire.

I've negotiated, capitulated, "just did the work", and various combinations of those three and it always come back to bite me in the butt. Any bug or missing function becomes my fault. Two or more years can go by, and it's still "your mess, fix it."

BTW, I'm not one to use the word "impossible" often, but this seems like one of those necessary times.

  • What is there to say about "cheap" when it's just one salaried FT developer doing the project? – krubo Jul 29 '18 at 22:19
  • 2
    @krubo you can translate cheap to lesser number of employees working on the project + no bonus for incremental/overtime developments. In this case, the OP is providing the company the cheapest work they can get. – CPHPython Jul 30 '18 at 8:45
2

You should use the Scotty factor: Whenever your manager requests a feature, you present an estimated duration first, before he has time to tell you his expectation. This estimated duration you multiply by 4 and then you let him negotiate you down.

Example

Manager: We need a production ready fleet management system in...

You [Interrupt]: Sure, I can create this in 4 months.

Manager: Oh, I was thinking two weeks.

You: Haha, great joke! You know that XYZ have been working on their fleet management system for 10 years and they just published their first stable version?

Manager: Well, we have two months at most...

You: I see what I can do.

P.S.: This trick is only necessary to that extend (multiply by 4) in a work environment such as yours. But it doesn't hurt to always plan a bit of buffer time in every project because we humans tend to plan for the things we know happen but can't account for the things that happen unexpectedly.

  • "I['ll] see what I can do" You just backed yourself into a corner ;) – Lightness Races in Orbit Jul 31 '18 at 16:27
  • @LightnessRacesinOrbit yes, a corner that's 2X your actual estimate. . . – iheanyi Jul 31 '18 at 19:28
  • @iheanyi Turns out I can't read ;) – Lightness Races in Orbit Aug 1 '18 at 10:08
-1

There is a widely cited and well known relation of three factors: Result

quality, duration and price

Only two of these can be achieved. It is so well-tested in computer science that we can just assume it is true. (Let me know if you do not.)

It is an actual fact, not something you can negotiate if he tries to enforce it, even at gun point.

The boss does not know or understand it: He shows that with

The end user does not see the tests, as long as it works and looks good it's fine, time to market is more important

He wants all three: no tests results in low quality, and the end user clearly see that as "it does not work (in parts - that is enough to make it useless)".

protected by mcknz Jul 27 '18 at 14:22

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.