New project is making me want to quit [closed]

Question

I work for a web development agency and we have recently taken on a legacy project for a new client who wishes to implement changes to their site. The current set of changes that I am working on are rather large and the framework is one where neither me nor any of my colleagues have any prior experience. The code is terribly mismanaged and the framework is difficult at best.

I am at mid-level and work in a maintenance team, though the nature of these changes is rather significantly different from anything before. Management asked me a few weeks ago to estimate these changes, and said they needed them quickly, and had little to no time to look into the codebase. I looked through designs and estimated the works on the face of them. Upon closer examination it has turned out that the work and project in general is far more complex. These works not only will take longer, I'm not even sure that I am capable of completing them within reasonable time at this point.

Here's the kicker. After my original estimates, management asked me to trim the fat and reduce development time further, with still little time to look into the project's codebase. I have started work this week and realised that it is likely impossible within the current timescales, however I have been told to meet those deadlines as agreed.

I generally enjoy my job and the projects I work on, however this one has come straight from upper management with almost no developer consultancy prior to me, and while it is rare, it is a situation that I have found myself in before. How can I handle this situation?

Answer 1

Since you already provided an estimate, in the future, triple your estimates! My general rule when providing estimates on software I've never worked on before, nor am familiar with the technologies used is to take whatever my initial hunch and triple it. This has saved my hide many times over the years, and it's now a best practice I live by.

That being said, since you already provided a number, your first job is to reset expectations now that you've dug in it a little further. It is ok to go back to the bosses that be and say it's going to take much longer, they're not going to like it given that you already have provided a number, so be prepared to mount a solid defense.

You should also work with the bosses and see if you can't subdivide the work into phases, and get your Minimum Viable Product (MVP) out initially, then work on additional features afterward ¹. I had a very large project once that was overwhelming, and once the project was divided into 3 distinct phases, it became much more easier to manage.

Also, if you are not familiar with the technologies used, you'd do well to see if you can find an expert consultant, then get a few hours from them to get you off to a good start, at least telling you the moving pieces and connect some dots for you. You can spend days researching/learning, or spend a few hours of time to get a fire-hose of information that will let you hit the ground running.

The biggest thing to deal with situations like this is communication, don't go into a box and come up for air one week before the deadline and then say you need two more months. That will just reflect badly on you. You should be giving updates to the business/your manager regularly, even to the point of putting work in front of them and asking if this meets their expectations, then you take their feedback and implement back into the product for the next round of development. This is the basic plan of iterative development using Agile software development. The key in this process is that you're constantly showing what the progress is, so when the deadline draws near nobody can be surprised if there's a lot 'missing' from the product.

---

^{1: A Minimum Viable Product is the subset of features which is minimally required for the end users to be able to use the application to achieve their basic goals. An example might be transportation: you might start with a skateboard as your first MVP since it'll get you where you're going. Then you'll build it into a scooter to make it easier to steer. Then you add features until you have a bicycle which helps you apply more power. Then you add features to make a motorbike and finally, you work towards making the product into a car. Depending on the exact requirements, it may be that the scooter is actually the MVP but in either case, there is some subset of the total list of features that will be enough to put the product in the hands of end-users, to start collecting feedback for the rest of the development.}

Answer 2

Having worked for a web dev agency I know exactly what you mean and had to learn quickly after having this exact same issue. Being asked for estimates by account managers and then haggled down on them.

The situation you are in right now, Id say the sooner you raise this the better. Tell them your concerns, what you have learnt and why its happened. If you highlight the problem rather than point fingers this will set you and the team on a good course to stop this happening again. The sooner you mention something the better it will be for you and the team involved.

Either try and get some time to research and learn the about the technologies or perhaps look at getting someone in that knows it for reference or to help work on it.

Here are some things I learnt when giving estimates in a similar environment to what you're describing:

1. You are mid level so chances are your opinion is respected and has some gravitas behind it. So when ever you are asked for an estimate quickly simply express you need time to asses the work to give a more accurate estimate. Even if they push, warn that its prone to being inaccurate if they rush you. This then puts the responsibility on them as you gave them forewarning if something goes wrong.

2. Caveats are king. Always caveat if you're not sure. For example "it will take 2 days if 'X', 'Y', and 'Z' are provided and clearly documented" or specify its a legacy code base and comes with its complexities etc "2 days providing we know the technologies, if not it will take longer" things like that. This makes the person asking aware that its dependent on there being no complexities that you haven't had chance to consider as you're being rushed.

3. Over estimate, five yourself atleast 20% breathing space at a minimum (more if you don't know what you're going into) that way if something goes wrong you have some padding just incase. Also you have some time to give back just incase you are asked to take it down you can afford to.

4. Communicate. Express your concerns, reservations and hesitations. They won't want to go to the client and tell them that either its going to cost more or its going to take longer. Constantly tell them and the client what you're doing and any issues there are, hopefully you're already doing this in a daily stand up anyway.

Answer 3

If the deadlines are not attainable and your estimate was not correct, you should communicate that up as soon as possible. There may be other ways to mitigate this that you are not aware of and letting it come down to the last minute is certainly not a good idea.

About wanting to quit: never quit at the first impulse, instead set a timer and see whether at the end of 30/60/90 days the same circumstances that make you want to quit still persist. Especially given this situation, the way the company handles it will be a very good signal whether it is a place you want to continue to work or not.

And for the future, practice #noestimates or get a lot better at estimating, uncovering risks, selling trade-offs and installing buffers inside your estimates to prevent something like this from happening again. Some of that you can learn from books but a lot of it comes down to experience (like this one).