71–80 of 163 posts
In fact, we actually just inherited this project (along with the mess) around 1-2 month ago from another dev team under the same manager, who have worked on it for a few month. That seems like a serious red flag to me. That manager's career is probably headed nowhere fast...
But no seriouly, if you want to stay at the same company after do what you're asked. Don't burn yourself out. If you're in a position to make change then so it. And if not then fire up your résumé ASAP.
I've picked up so many of these types of projects, it's sort of become my specialty. The first thing to do is to ask oneself if it's worth completing the project at all. All stakeholders _will_ have to be ready to make some sacrifices; is it worth it? Also, like others have said, communication is key. If the team can't have open conversations up-front, it may be best to walk. But, if the team can communicate openly a…
The guy clearly said he is a developer. While your advice is sound, it is something that only the manager has authority and responsibility to do. It is just impossible it almost any organization that a developer can turn project and project methodologies upside down like suggested here. > However, in the end, it is also completely ok to walk away, especially if there's no incentive to continue.
Which mean you could change all of this, by winning over the team - and not missing deadlines worse than you were before....
Choose from 2 extreme alternatives: a. Treat this project as if it were your sick child on life support. b. Treat this project as if it were a gazelle being ripped apart by a pride of lions. If you choose (a), do anything and everything you can to save it. Be open and sincere and stop at nothing. If you choose (b), prepare a resume and run the other way. No sense risking your own well-being on a lost cause. The worst…
So do a death march or quit? Very extreme. Unless you're in a tiny company that will literally go out of business if the project isn't complete, there is a valid middle ground: cover your ass to avoid blame, pitch to the PM to get the schedule extended, salvage as much as you can, and move on and do better next time. In the meantime, take a better job if one turns up. But don't be lured into extreme action by magical…
Taking a better job is fine, but halfway a project it might kill the project when some of the top guys decide to leave. It might even be worse when the architect of the legacy-system decides to leave with knowledge of all the undocumented business rules.
It's so important, that a project is well managed, because a lot of the aspects of building something new are extremely satisfying to work on. However with mismanagement it's easy to demoralize the team.
Choose from 2 extreme alternatives: a. Treat this project as if it were your sick child on life support. b. Treat this project as if it were a gazelle being ripped apart by a pride of lions. If you choose (a), do anything and everything you can to save it. Be open and sincere and stop at nothing. If you choose (b), prepare a resume and run the other way. No sense risking your own well-being on a lost cause. The worst…
The severity of the consequences determines what approach is best to take-- and there are many choice in-between working like a mad-man and dropping everything interviewing for a new position.
Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not try to impose your conclusion on them. Management must always have the choice of what to do, but it is your job to assess and communicate the situation. Use email, so as to leave a paper trail when things go south. I hope future historians will be astonished that all of us chose…
I've had employees try to the "build a better solution" approach behind my back. The big problem with it is that it assumes the person actually has the full picture. In a small project, that may be the case. But often it isn't. In the case I have in mind, said employee delivered a solution that did in fact do most of what our current solution did very well with little complexity. But it utterly failed to account for…
Also, its possible you pick a stack that causes all kinds of re-training, contracts to die, systems to redo, that doesn't scale to the number of production users, has other unexpected costs, etc. maybe the code is written fast but is hard to maintain. Maybe you have vendor agreement. maybe you have client agreements about where the database can be located. Who knows.
Lots of variables. And you can't see this beforehand. Never ever do this without at least some management buy-in. Someone who is on board with you and can help better define the requirements and explain why things are done this way
Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not try to impose your conclusion on them. Management must always have the choice of what to do, but it is your job to assess and communicate the situation. Use email, so as to leave a paper trail when things go south. I hope future historians will be astonished that all of us chose…
I've had employees try to the "build a better solution" approach behind my back. The big problem with it is that it assumes the person actually has the full picture. In a small project, that may be the case. But often it isn't. In the case I have in mind, said employee delivered a solution that did in fact do most of what our current solution did very well with little complexity. But it utterly failed to account for…
In fact, we actually just inherited this project (along with the mess) around 1-2 month ago from another dev team under the same manager, who have worked on it for a few month. That seems like a serious red flag to me. That manager's career is probably headed nowhere fast...
Putting an entirely new team on an existing code base is madness.