As a developer; Not getting time to test, receiving extreme deadlines and not being listened to by the manager

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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

Explain to your manager the following triangle:

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.

Answer 9

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.

Answer 10

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.

Answer 11

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)".