Be professional. State your concerns to your manager, and probably a level up as well. Make it clear that you don't have any confidence in the project as planned and you think that the cause is a hopeless one.
Then (assuming you want to keep working there, as the author seems to) make it clear that if they still want to go ahead then you are fully committed to helping them to the best of your abilities.
But a project in as bad a state as described?
Get another job.
+1. Communication and professionalism are your best bet, here. It's amazing how often engineers think the managers know all these things, as if they've mentioned it a million times, but no one is listening.
Sometimes the problem is that the issues are communicated, but not the severity. So, you might raise that the database is too complex with 100+ tables, but if the manager does not have an intuitive sense for the consequences of that problem, it might not register as a project-destroying issue. That becomes the disconnect later, and when things go pear-shaped, these disconnects become issues of contention.
The worst thing you can do is to raise these issues quietly and just keep trucking, as if you've done your job, and that's that. [wiping hands gesture] If management doesn't realize that the project is headed for disaster, that's on you (and the others on the team).
But, if you're able to convey the severity of these issues clearly and professionally, the conversation might turn to what can get done in the near term that would be valuable. Or, to the point of other commenters, there might be other factors at play, and the manager might want you to keep trucking anyway. In this case, provided you have been clear about the risks and threats, you really have done your job.
As a parting thought, you could also raise an issue around "what type of company" you want to work for. Perhaps if they need to rock out a rough proof of concept with no automated testing (or any testing!), that's one thing, but I wouldn't want to work at a company that doesn't take testing seriously. So perhaps if this is a manic sprint to prove something, we can all get on board with cowboy coding, but once the dust settles, it will take x amount of time to shore up the work with xyz types of tests. If they aren't on board with taking their medicine and putting the right tests in place, then that might be reason to depart even if the proof of concept succeeds.
The downside to such a strategy might be that the reason for the impending failure is the manager, and/or the level up as well.
Most organizations operate (and should operate) according to what the top-level decides should happen. If the top-level defaults on that responsibility, then chaos will ensue.
In those cases a value judgment of the process is a value judgment of the organization, and most astute managers realize it sometimes before the "innocent" (i.e., socially naive on organizational dynamics) system builder guy realizes it.
Well yeah, the reason I mentioned the level up is that sometimes your manager is the problem, and sometimes your manager isn't telling the business about the problem.
If both of those are part of the problem (don't worry! All is well!), rather than realistic (we know there are serious problems here but we think there's a chance/we'd like to try anyway), then it's time to think about the systemic problems and consider finding yourself a new job (IMHO).
It's deliberately dramatized but I don't really see it as wrong. Here's how I would (less dramatically--and less interestingly)phrase the choices.
a.) If you're sure there's a path to success and you're invested in getting there, do whatever you can to achieve that goal--understanding that one of the possible outcomes is to be told to pack your things and leave. Now. The likelihood of this outcome obviously depends on the exact situation.
b.) Accept that things are not going to end well. Do your job, keep your head down, and start seeking alternatives ex post haste. In some situations, seeking alternatives ex post haste may, in fact, involve fleeing (especially in a short time horizon such as this one) but I've certainly been in situations where the writing was more or less on the wall but more in the vein of a long ponderous collapse.
Fresh gazelle is delicious. Try not to overeat. There's a whole heard, and the pride will catch another one tomorrow. It's all a matter of perspective.
It's graphical, but not very helpful. How would the employee go about saving the project? The manager has authority over him/her, so their only choice would be to convince the manager that a drastic change is needed. Yet no manager is going to be receptive to the truth that they've personally failed over the past 1.5 months to such an extent that the next 1.5 months are impossible to salvage without throwing away most of the existing work. That conversation would not go well for the employee.
> It may be graphical, but it's not very helpful. What is OP supposed to do to "save" the project?
I would disagree there.
A good manager might take the situation well - they may have been misinformed by others and think things are far better than they are.
If that isn't the case there may be the option of going above the managers head, though this has to be considered very carefully. In may case once it went rather well: the person above me had grossly misreported things above him. We are still dealing with some of the legacy of that period, but getting through it (and that person is no longer here). Of course depending on local politics this could go very badly, so I'll repeat: consider this sort of action very very carefully before taking the step.
In my case saying "things have been X bad for a while, if things don't change either we are going to fail badly very soon or I'm going to burn out inside a couple of months" got the message across (it turns out an honest assessment was appreciated and that not losing some of us through walk out or burn out was important enough to warrant rearranging some plans and expectations). Of course I'm lucky: the Powers That Be here are sensible and I've been here over a decade & proven myself a good few times over so my word carries some weight - a relative new-starter under a less receptive hierarchy would not fair so well.
If there really are no options for plan A for whatever reason, no end of time/overtime will fix the problem and there is no way the management can be made to appreciate the scale of the problem, that leaves plan B: get ready to jump ship.
All good managers rely on the people under them to give them high quality information and feedback to make decisions. don't blanket all managers as being too egotistical to avoid irrational escalation of commitment.
That being said, decisions like reversing project directions or pivoting are usually huge multi-party decisions not up to a single person (unless it gets escalated to the very very top).
A politically savvy employee would be able to make it work. Albeit, after saving the project (or making an admirable effort that catches everyone's eye), that employee would probably be marked by management for a management role. ;)
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 thinking. If a failed project is inextricably linked to your personal well-being, you're in the wrong business.
I agree, that the previous comment sounds extreme, there often is a middle ground. People can be reasoned with, otherwise the company you're working for doesn't sound like a good place to be.
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.
> 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.
Exactly. The world is pretty small and you shouldn't step on somebody's toes unless you absolutely don't see another way out.
The sensitive thing to do here, is to make sure you've got your ass covered and if this is a persisting problem or you feel like you can't work there anymore, then you quit after the current job is done. And hopefully you can leave with a good recommendation.
Maybe it sounds extreme, but I agree with @edw519: you don't want to work at a place that lets a project fail as badly as the OP described it. I've been in situations like that too often and I've learned that particular lesson too well.
Like @angdis said elsewhere in this discussion, projects "fail" all the time, but the OP is talking about a specific kind of failure. Notice how many commenters mention "finger-pointing" and "paper trail". When you find yourself in a situation where that becomes important, it's time to consider leaving and it's always better to leave on your own terms.
Unless you're deeply invested in that project or that company, it's usually better to start looking for a place where projects fail more gracefully than this.
I think that level of "failure" isn't exceptional in the field.
It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B".
"Team B" usually finds many deficiencies at work in the code. For instance, people frequently bungle the design of 10-table databases, so perhaps there are dragons in the 100s of tables.
"Team B" sometimes delivers the product, usually late. Sometimes it doesn't.
That's life. The Gartner Group says that 2/3 of all IT projects fail and I think that's about par for the course.
> It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B".
First: why is that? Are there good reasons for this, and does this happen for those reasons?
Now, knowing nothing about the company, if I learn that every other project suffer a change of team before going into maintenance (officially and actually), then it's substantial evidence that something is wrong with management.
Whether one should quit of course depends on how wrong.
That percentage is about right for all organizational change. The data also suggest that implementation, not bad ideas, is generally to blame. Possible solution: change the situation where you do have the influence. Work across all the dimensions of people, tech, & org process to find how you might make a suggestion that will stick. I gave that advice to 40 folks just yesterday in class (I teach org design & innovation management at Santa Clara Univ).
I wonder if a company culture that is heavy on blame when things go poorly is conversely liberal with praise/rewards when things go well? Might not be that bad of a place to work if so.
In what universe would this hypothetical company exist? There are plenty of companies organized solely around blame and finger-pointing. They are terrible companies that no software developer should tolerate.
Dreams are free. In the real world, management will typically take all the credit if things go well, for the same reasons as they'll blame-shift and arse-cover if things don't.
The fact is projects "fail" all the time. One has to really define what failure actually constitutes. It can be anything from the completion date skidding a few weeks or months or perhaps something worse like no chance in hell of ever completing the project to the satisfaction of the customer and going out of business in the process.
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.
70% of projects fail. According to your options you're either burned out pretty fast by going the extra mile, or you change jobs every couple of years.
IMHO the best thing to do is to express your concerns and from there on just do your job without investing any extra effort. You can't be reluctant cause this will be received as not caring, neither invest the extra effort because usually the reason projects fail is not incompetent programmers but wrong specifications. Let someone else take the blame.
It's not ideal, but if he can put himself in a position where it's obvious to management that the project didn't fail because of him, I don't think he'll end up too badly off. If the parts of the project he's worked on are well put together and working well, then it doesn't look too bad on him that the overall project failed.
On the other hand, it sounds like a depressing situation to be in, so I'd prefer your option (b).
There can be mitigating circumstances that could warrant staying, but mostly I have to agree with you. Either fight to turn things around or avoid being stained by the inevitable failure.
The worst thing about staying to turn things around is that often the failure is set up from the beginning by those in leadership. Your reward for working your ass off to make the project succeed is probably going to be to make someone look good who was responsible for digging the hole that you helped to pull everything out of.
Unless the game board is set up so that you benefit heavily from your hard work (equity, bonuses rewarding the risk and effort) - there's little upside to killing yourself besides some opportunity for personal growth.
It makes sense if you're absolutely, positively sure that the project is doomed and there's not a slightest hope for it.
But even assuming this, choice (b) is only local optimization. One could consider instead doing (c) - to try as hard as possible to convince the management to shut down that project ASAP, and thus saving the company many man-hours of wasted work. The global gain will be much greater then. Of course if management is stubborn and you're still sure the project will fail, then you're back to option (b).
I just today talked with friends that work for Samsung and the amount of wasted everything they told me about was staggering. I don't think that there is anything such companies couldn't waste and forget about. This makes the management stubbornness all the more probable and makes trying to save "work-hours" pointless. That's pretty scary shit, but apparently that's how it works in such companies. I don't want to ever work in such an environment.
Yeah, I guess it depends on the size and make-up of the company. When I was writing that comment I was imagining a small/medium sized company, doing one or two big projects at the same time. If the company is so big that it can waste everything and still go forward by its inertia, then I guess leaving promptly is the right choice.
There's a good idea here, to manage your level of commitment, but it's lost in the idea that it's a binary decision.
To get high performance without burnout it is necessary to switch from complete engagement to complete disengagement every few hours.
The Serenity Prayer from Alcoholics Anonymous is asking for the right thing here, even if you aren't religious.
"God grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference."
It's great to be passionate but it's also important to be detached about things you can't control.
One detail that is missing from this story is the nature of the deadline. Lateness is endemic in software development, and successful projects often get delivered years after they were promised. Late doesn't necessarily mean "failed."
You can't go wrong learning more about project management so you can have a more correct understanding of the situation.
Whatever you do, keep your honor. Being ambiguous about wanting the job gives you the unique freedom to refuse any order that you truly don't want to carry out.
It's great to be passionate but it's also important to be detached about things you can't control.
This is fantastic advice, and one of the main things I tried to drill into my team (when I had one), with fairly mixed success. It's very hard to convince people who are attached to a project that they should at any point just go "meh, what can you do?" but sometimes that really is your only option. Advice for any startups in this situation - if you really have to impose some awful condition on your workers, make sure you explain it fully to them. It's easier to accept something you don't like being imposed on you if you understand it, even though you don't agree with the reasoning.
Another really tricky fine line is, having done this a couple of times, to then stop people going "meh, screw it" when they really can control the outcome, but just don't feel like it for whatever reason.
You are in the pride of lions. You do not know it yet. What many coders don't realize is how much power they actually have.
You are the lion and the resources of the company are the gazelle. It's time to feast!
It's really a good time to:
1) ask for a raise for more "effort"
2) ask for more budget
3) that new computer they've been holding out on.
Ya, you can ditch that 17" laptop from 2006. ;) Just ask!
We know that throwing resources into the game this late doesn't work, but it's good to have that extra budget for later just in case you wildly do succeed.
In a culture like that appears to be, it's pointless to be that guy screaming about the upcoming iceberg. No one will listen. Far better to be the guy with solutions once fail happens.
Frankly this sounds like the sort of environment where introducing scrum would be a big step forward. As the developer, knowing a good scrum consultant to introduce to the company might be a good move, once the fail happens.
I'd be hesitant to raise concerns, on what appears to be a relatively small project, in case you become the scapegoat and a way for either the manager or your colleagues to point the finger at you for not being a team member and hence the reason the project failed.
Since it's only 6 weeks to the deadline it is probably worth pitching in and trying to make it work. If failure is going to be a big deal then you'll all be looking for jobs anyway. Alternatively it might turn out that the deadline was not so crucial and you will be able to sort out the mess.
Always remember that rats are first to desert a sinking ship - you don't want to end up with being labelled as such.
The rats are first to know what's going to happen because they're deep in the bowels of the system - dirty, dank, ugly, but know the real story. Looking for and taking an exit can be the smart move if you know the boat is going to sink.
Being upset at being labeled a "rat" means you're alive.
This pervasive "don't raise concerns or you'll get targeted" is all too often WHY projects fail: people keep telling the decision makers "everything is fine, we'll deliver on time" while mumbling "ain't no way this thing's gonna make it" in dark corners, leaving those with the power to do something about it unaware of the problem approaching, and looking for heads to roll when it does. If you're going to be punished for speaking up (objectively, professionally) then it's time to get out of a toxic environment.
I completely agree. It is the short timescale that makes toughing it out worth considering. If the project had several months to go and not just six weeks then speaking up or getting out would be the correct courses of action. From the problems described in the OP it seems unlikely any fixes can be applied to avert disaster.
Honest, "be slightly evil" answer: say absolutely nothing. Just work. Get done what is asked of you. When you have free time (which you often will, due to the chaos as things start to shake) use it to build skills for your next gig.
People will probably lose jobs. Sometimes that will happen based on seniority and sometimes it's just random. Sometimes, that will happens to the PITAs who spoke up and happened to be right. You don't want to be a PITA. PITAs become blame dumpsters even when they were right, because enough people hate them and no one will defend them. You're not the only one who knows that the project is fucked. Just keep your mouth shut about the fact.
There's something I call the Welch Effect, which is that the people most likely to be laid off are junior/least-established members of macroscopically underperforming teams (who had nothing to do with its underperformance, because they had no power). Managers are sometimes sympathetic to the Welch Effect and will set a "no infanticide" rule, but not if you're a PITA.
Keep your head down, do good work when work is asked of you, and start planning for your next move. Start networking and searching and building skills now, not when you need to.
If you lose your job, don't take it personally. It's not your fault, and if you tell the story in the right way, no one will hold it against you. These things happen to good developers, especially early in the careers, all the time. Most projects fail. It's not like school where something has to be going wrong to fail a course, because only 5-10% get F's. It's probably 50-75% of software projects that fail.
"Do as you're told" and "Don't talk back" are probably the worst "rules" I've been taught in US grade school. Following that mentality will net you exactly this: a miserable and close-minded life.
DO voice your opinion and professional expertise.
DO make recommendations as to how to salvage or improve a project. Not doing so will not get you anywhere.
That's not true. Being able to endure and suffer silently is a skill that is often the way to survive through struggles and win the game in the end. It is mostly the case for politicians and mafia members, but it is also useful for developers.
Sure, you can play the endure card and just do your job in the hope of one day pulling ahead of everyone. But what if that isn't the case? What if you silently work your ass off and then get laid off anyway? If there's one thing I've learned, it's that you earn what you put in. It's in your interest to push the product, create a drive in the company and basically make it the best environment for you and everyone else to work in. And if that is met with nay-sayers or incompetence, then you should be moving on anyway.
I'm not advising anyone to "silently work your ass off" because that doesn't work either. If you're on a failing project that will harm your career, leave. But leave silently unless there's a credible chance you can fix it (and usually, you can't).
If the project is doomed to failure, being a PITA means you're more likely to get fired while silently working out a transfer or next gig has only upside.
I love how this idealism is so accepted here, sure it works, but there is plenty of good in "staying until the job is done", you just don't believe it.
I don't think michaelochurch is saying that. Rather, sometimes you look out for #1, which involves doing your best and setting yourself up for long term success.
I'm not saying he needs to stick with the project. I'm saying that it's, on average, bad for your career to try to save a failing project. Better to move to one that will succeed, but you don't get mobility by offending everyone around you, which is often what happens when you try to "save" people in spite of themselves.
Exactly; I have a bad habit of saving failing projects, generally of companies that had to have them succeed, and very seldom got any thanks from it, even when I was explicitly hired to do just that (sometimes was even purged when technical success was achieved but not cemented, causing the company to later crater). If there is a gentle way of doing this it was beyond my limited interpersonal skills, and I agree with everything Mr. Church is saying here, if you can pull it off (I can't): keep your mouth shut while you pull the ejection handle.
Or to learn how to differentiate projects that are within your power to save from those that are not.
If you're a developer, you often can help save projects that are failing because they were poorly outsourced, or handed to the wrong team, or technically flawed. You usually can't save projects that are failing because management never really believed in them, or that are caught in crossfire between conflicting factions on the corporate board, or that have never been funded/resourced at the levels required for success.
Right on. Working conscientiously when easy excuses for doing otherwise are in season is the essence of professionalism. Providing one's best given the circumstances is the core character trait. Deadlines move, budgets expand, requirements shift and staff move on (including managers). All are beyond the line worker's control. Sometimes, life includes a deathmarch. You still gotta' throw strikes when trailing by thirteen in the top of the sixth.
This is probably the most important piece of advice in the whole discussion. Getting all worked up about someone else's responsibility.
Another interesting side issue not explored yet... I believe its a distorting factor that he has semi-privileged information and opinions about his own area of expertise. If he had semi-privileged information and opinions about the supply of packing tape in the shipping department, or the technology level of the forklift battery charger in the warehouse, he'd wisely be advised to stick to casual careful gossip unless its human safety critical, aka just do his job... at work. At home, if certain that the battery charger is going to cause irreparable financial harm, sure, go update that resume... just keep it at home.
Real businesses can be messy and inefficient and petty and stupid and still turn a handsome profit. They usually don't participate much in our Platonic ideal of one.
One of the tracks of the discussion here and on Stack Exchange is to elevate the situation to a plane requiring moral decisions. And it just ain't so. A line worker does not have fiduciary responsibility, and as you rightly point out, this doesn't entail issues of life safety, public health, or economic exploitation.
It's just normal muddling through.
The biggest hazard to the person posting the question on StackOverflow is erroneously assuming they are the smartest person in the room, or in its most common form, that everyone else is an idiot. Trains are big loud whistling contraptions with bright lights. Unless distracted, few people fail to see and hear them coming.
Mr. Church is absolutely right, and I have a telling story from the decline and fall of Lucent to back it up:
The last project I worked on was something essential to Lucent's survival as an independent entity. Many of you have heard of sophisticated telephone switches, like the Western Electric (AT&T) then Lucent 5ESS (http://en.wikipedia.org/wiki/5ESS), a really impressive monster that's truly 5 9's reliable (or it genuinely tried to be and by and large made the grade).
The new way of doing this is (or was as of 2001) to split the functions of such a switch into a Media Gateway Controller AKA Call Agent e.g. the Lucent Softswitch, which understands things like billing, and a Media Controller which does the actual work of connecting A to B and converting as needed (e.g. POTS to VoIP). There's even a dual ITU/IETF protocol for communications between the two, Megaco AKA H.248 AKA RFC 2805.
It should be obvious that being able to offer a complete solution was essential for Lucent's future, as conventional switch sales were at least projected to plummet, and my group was part of effort to create the other half the company needed, the Media Controller. Which was a challenging thing, including that true 5 9s reliability requirement (just say no to hard disks, I was among other things the database guy in testing, and the operational database lead and I had to vet and sign off on each other's designs (mine was a data warehouse approach for storing fine grained events generated by the test system, Oracle was real fun for that sort of thing and we had a 106,000 seat license (!) from them, although headcount was going down to 35,000), and I was personally responsible for testing his system).
ADDED: going off the Yourdon Death March chart included in OP comments, this was a "mission impossible" project, high happiness (fun, challenging project), at least a decent chance of success initially (e.g. we were working with the 5ESS people, who taught us a lot of neat stuff about real 5 9s.)
Anyway, at a certain point, completely insanely a company wide headcount cull was applied to this effort, and I'm pretty sure it was sufficient to kill the project (my testing area was gutted, going from "maybe, just maybe we can get this work done in time" to one engineer plus a little outside help, with one manager, a failed programmer so she wasn't of much if any help).
One of the things that really stood out was the layoff of a pretty famous person in the company, a jack of all trades who e.g. had the energy and skill to take the chosen (Linux based) RTOS from the vendor and get it up and running in our environments, kick the tires and minimally validate it, etc. Don't know if he was a PITA like I was in part, but it's hard to imagine he wasn't at least a bit, he was the sort of guy who was in a position to say "This won't work because I just tried it".
The managers flaunted his layoff like a badge of honor, an implicit "If this guy can get fired no one is safe", and blatantly lied about the grounds. They claimed he was "inflexible" about what he'd work on, when it was a very visible matter of written record that he'd very productively work on just about anything. I never even talked to this guy, I just learned of his background and merits from the written progress reports and mention of him in an occasional conference call meeting, he was perhaps the most visible "exceptional" employee in this make or break project.
And yet he was purged.
(As was I, although that was by abuse from an envious boss and may not have even been part of the headcount cull; while I wasn't hardly so visible, I was the only serious software engineer on the testing effort, and there was no way the company could build the new test system without someone of my caliber. And you'll never create a true 5 9s system without serious testing.)
And as many of you know, the bottom line is that Lucent was bought by Alcetel and is a shade of its form...
I definitely agree with michaelochurch to avoid being a PITA, being right that project will fail isn't productive professionally or personally. Being the person to tell a smoker that they are likely to get cancer isn't helpful to them or you.
If you're going to stay around pick something that you think is the most important function/feature and make sure that it is amazing. There is almost always some smart people around and some new things to learn.
Taking responsibility for things over which you have no authority will make you miserable and crazy. Find out where your authority stretches and make the most of that area leads to amazing developments. I can predict that the education system will continue to suck tomorrow and there isn't much I can do about it but tutoring a few students at my local school can really make a difference in their lives.
If you are the only one that is seeing the upcoming failure, this can mean 2 things:
1) You are wrong and paranoid. The project will be delivered with some hurdles but will not be catastrophic at all. Try to make sure that your concerns are clearly defined. Contrary to most people here advise: don't try to be the nice guy by being subtle. Be polite but be also confronting.
2) You are right and you will not be able to change the situation. In this case, I would choose the easy way and leave for another job. Watch out for the stockholm syndrome: there are other companies where you can enjoy your work. Don't feel to much sympathy for the current situation or be afraid of uncertainties that come with leaving.
Sometimes it's hard communicating the situation to a manager as opening that pandoras box can end up meaning you spend more time giving status than doing the actual work.
But not communicating is not going to help anyone, unless you feel confident that you can get the project back into shape.
So the deadline is missed. It happens. The stakeholders need to be prepared and they need to have runway to take action. Finding out in the final week then being asked to train up 10 new contractors is not going to work. Managers know that it doesn't work, but more often than not they feel that is the easiest way to help.
You shouldn't give up your personal time unless you feel there is some reward, otherwise you will just feel bitter and leave the company in the next crisis. I gave up a lot of personal time to save a project. I did it for my own credibility and passion, but money, time off in lieu and promotion are the rewards that keep employees. I got one week off (after giving 5 weeks of personal time), and £250 of vouchers (but only if during this crisis, I worked a Saturday on someone elses project). I left that job within 12 months.
If anything else, you'll learn the experience of what works and does during crunch time.
If a project is so obviously in bad shape, management should be aware, otherwise they are incompetent. Therefore there is nothing to be gained by telling them it's messed up. Typical business time-frames do not allow for an entire team to start over on a project. Going rouge and creating an alternative solution is an option if the developer feels strongly that there is someone in management who will appreciate a better alternative and only needs a working proof of the idea in order to embrace it, but lacking that confidence, it's probably a waste of time.
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 to accept such insanity without doing anything to change it.
Thought experiment: There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks. The project has been in development for 1.5 months and has 1.5 months to go before the deadline. Their current solution apparently involves relying on a relational database as some kind of programming language or configuration system (100+ tables). There's a good chance that a developer with ambition and talent could singlehandedly deliver a superior solution within a short timeframe.
So what stops the developer from executing? Primarily his own (fully justified) fear of negative consequences. But the only reason his fears are justified are because of structural problems in how companies operate today: managers are expected to drive the direction of the project and are given the authority to do so, and the authority to fire anyone who won't go along with the manager's vision. That makes it impossible for a developer to make sweeping changes and be perceived as doing anything but challenging the manager's authority. But it's not about authority. It's about the customer. It's about making good products. Yet the environment is set up so that the developer concludes that it's entirely justified to be afraid; to sit quietly and do nothing. And it's precisely this collective fear that drives this sort of degeneration within companies.
There has to be something better. I want to try to build something better. Some new way of thinking about how to build a modern software business. Profit sharing, maybe. It might be possible to set up a company such that it could pay its employees a percentage of the profits. The first employee would get 15%. The next employee would get 7.5%, and the next 3.75%, and so on. Then as the company makes profit, that profit is continually paid out proportionally to each employee.
That system has all sorts of flaws, though. One example: an employee should only be getting a percentage of profits while they're at the company. They should be getting their full percentage on day one, and should give up their percentage on the day they leave the company. But I can't think of any mechanism which would actually let a corporation pay out like that. If you tried to pay out profit via dividends, then you'd have to allocate the percentages using stock, and employees don't typically get stock up front on day one -- it takes several years to vest -- and they don't lose it when they leave the company. So profit sharing via dividends wouldn't work.
The idea is to provide an incentive to employees for projects to be useful to customers. There's currently no incentive. Employees are generally expected to play the politics/career game in order to secure a safe future for themselves. I guarantee you that if the employees at OP's company had been given some percentage of future profits, then they would currently be revolting and calling out that manager's behavior and incompetence.
"...There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks"
These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality.
Complex systems tend to have many written and unwritten requirements that aren't captured in their clones.
Anyway, I would not look at 100+ relational tables as being a bad practice in and of itself. I've worked on plenty of systems of this complexity, and it's really no problem at all if you're systematic. You need to have a machine-readable data dictionary and you can't be writing all your SQL by hand.
Yeah, the 100 table thing threw me as I regularly work in business software with over 1000 tables.
The count of tables is less important than organization of them. If you have a clear structure and set of relationships, it is not too difficult to chunk their concerns.
These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality.
Well, I've done it. I've developed complete solutions to business problems that the company was trying to solve. I did it without waiting for permission or for my design to be approved, and I did it only after I fully researched and understood the problem space and the future goals of the company. Then I made sure the design took into account all of those future contingencies without being rigorously bound by them, i.e. flexible and not a hindrance when the business goals change in the future -- which they always do. At the most recent company I worked for (a massive corporation) the system is expected to be in production for the next 3 years at a minimum. I did the first 90% of the work in two months, then the other 90% of the work in another month or so. The fourth month was spent primarily on training, documentation, and meetings.
Competence exists. The managers are simply given the authority to squander it or to perceive it as a threat and fire them. I was lucky enough to have a manager who was receptive to me overstepping my bounds as a contractor. I made decisions (such as making Redis a core requirement of my design) before asking permission or waiting for approval. I presented a demo of an early version of it to my manager at the end of my first week, and thankfully he was both surprised and happy about it. (40x improvements to the existing infrastructure tend to elicit that reaction.) But most large corporations, and even many small ones, aren't like that at all. You'd be fired for overstepping your boundaries, whether or not you were capable of making a difference to the bottom line. It's up to the manager, and that is a wholly backwards way of running a modern software corporation.
For software companies, there has got to be a better way than the existing approach. At the very least, the concept of a "manager" should be divided into two people: a manager and a producer. The producer's role is to drive their project's goals. The manager's role is to ensure that the employees are happy and to deal with roadblocks (such as if an employee needs to purchase a third-party tool). The manager has the authority to fire people; the producer does not. The manager's goal is to look after the team, not the project. And neither of them can tell an employee what to do. The employees are given tasks to complete, not steps to complete, and then trusted to complete that task. The employee is trusted not to accept tasks which he/she feels are too ambitious for the producer's timeline. So the producer can only barter with the employees, not demand from them.
I know of a massive videogame company (not Valve) which operates that way, and it's the reason they're currently the industry leader in their genre even though they've grown exponentially as a company over the past four years, both in employee count and customer count. So it absolutely worked for them, and I'm willing to bet that it would work in a lot of software companies. I want to prove that it works.
GP said the weekend. You did your thing in a quarter.
Maybe I've been lucky, but in nearly a decade of technology work I have never been penalized for 'overstepping my bounds' by improving something important. I think improving important things is within everyone's bounds, tbh.
> There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks.
I can practically guarantee (and the OP strongly implies it) that the problem with this project is not that it is hard to implement, but that its requirements are unspecified.
Rewriting it in a fancy feel-good language changes exactly nothing and should be treated as an act of sabotage, because it is exactly that.
The project is already sabotaged by bad management--a rewrite in a fun/easier language at least means the band will be playing when the ship goes down.
" There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks. "
When I was younger, I would've actually done this. As I got older i learned some things, and one of those things is that 20% of the work will take about 80% of the time. I'm sure he could take a week or two, develop a kick ass demo that demonstrates a working concept... but it won't make the project finish sooner. Rewriting existing code that's hard to work with is essentially defaulting on technical debt. If he skips essential things like writing a proper design doc (documents are a really good way i've learned to communicate with your team, don't skip them!) if he doesn't have good code coverage, then he's simply taking out a new loan.
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 the strategies that were in place for future functionality, that placed very different requirements on the platform. As a result his solution was of no value to us.
There was serious discussion about terminating said developer because of the amount of time he'd wasted on that, and the discord it created in the team when he tried to push his "solution" as an alternative to the existing system.
Often the direction is set by managers for good reason: Sharing every bit of detail would paralyse even relatively small organisations.
That's not to say that skunkwork projects like that can't work or be beneficial, but in my experience the odds are high that they will overlook something important. Before doing something like that, the developer should at least put in a lot of effort to try to learn exactly why the current project is the way it is.
This is a very good example. Yes you can re-write it, and assuming you succeed, you may not know the future direction and by making assumptions to make things easier very much lock yourself out of those options.
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
> But it utterly failed to account for the strategies that were in place for future functionality, that placed very different requirements on the platform.
In other words, he pissed management off. He busted his as off trying to improve the product and was rewarded by being treated like shit. It really sounds more like he was railroaded by company politics by stepping on the wrong peoples toes.
> In other words, he pissed management off. He busted his as off trying to improve the product and was rewarded by being treated like shit.
No, he wasted valuable time and company resources attempting to do something that wasn't needed, or asked for, and provided no value (arguably negative value) to his team in doing so. Of course people work hard and aren't rewarded for it, but it sounds like it's the case here that this cowboy was trying to outwit the system and ended up hurting the team a lot with his irresponsibility.
I've watched this scenario play out on multiple occasions, in different variations.
In one memorable case, the developer missed some pretty important requirements that mattered a lot to management but did not matter to him. The developer certainly felt that he was railroaded by politics. But I, as an independent observer at the same level, could easily see that management was right to want what they wanted, and that the developer was too emotionally invested to see what he was missing.
Same company, same team, same developer, a different project, not too long earlier. He went off and developed something that really did meet the needs we had, and got rewarded for it. The difference is that he actually understood the requirements and nailed them.
Drive, ambition, technical chops, and an unwillingness to listen first can get a lot done, very quickly. The same characteristics can create a lot of conflict very quickly as well. It is hit or miss which happens in any particular case. And on the misses, management is easy to blame but they are not really to blame.
Did you actually read what I wrote? Including the sentence you quoted?
He busted his ass to deliver something un-asked for that didn't meet more than maybe 5% of our requirements and didn't improve the product in any way, rather than doing the job he was paid to do, because he decided he knew a better solution without knowing or understanding what the full requirements were.
Had he come to me and asked if he could do an experiment to see if he could rebuild part of the system simpler, we would have discussed the idea with him. If he gave me reason to believe he could meet the full requirements rather than what he thought the requirements were, we would certainly have entertained the idea of giving him time to prototype something.
But he didn't. He made a ton of assumptions that were mostly wrong about what the system needed to do, because he was not privy to e.g. the strategy discussions the board and executive team had, and the discussions we'd had with investors.
That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots. While doubtless sometimes they are, a lot of the time they simply have more information than you.
Do you honestly not see how someone that takes an initiative like that could be an incredible boon to a company? When you punish people like that, what you're left with is an office full of drones that does exactly what they are told, nothing more nothing less.
The situation you're describing is a management failure of epic proportions. Failed to communicate future planned features to dev team. Failed to exploit someones willingness to take responsibility. Failed to get input from the programmers (obviously at least one of them thought the code base was a mess).
Oh, and hiring someone who believed making a good product was more important than following chain of command. Big mistake there.
> That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots.
Even construction workers always knows what they are working on and why their work is important. If management is unable to communicate to the developers what purpose their work serves to the company then that is incompetent beyond belief.
Why weren't you communicating the strategy and vision for the product? That's a failure of management. Each layer in the structure should be given and understand the vision and goals of the immedeiate layer above them so that they can creatively execute and improvise excellent solutions instead of being locked into a plan.
The overall strategy and vision, sure. But you can not spend tons of time making sure every team member understands every little detail of what implications it has on projects far outside of their remit.
At some point, especially when dealing with senior developers in a fast moving startup environment, you have to assume you're dealing with reasonably responsible engineers who understands that if something doesn't make sense to them immediately, their first instinct should not be "I can rewrite this component that isn't remotely part of my job in a few weeks, no need to ask anyone", but rather to ask "what am I missing? Please explain this to me".
I've personally come across many cases where something looked trivial to do better, and occasionally I'm right, but I'm also humble enough to go ask the questions before I put aside the work I've been asked to do and go off to rewrite something else.
> Often the direction is set by managers for good reason: Sharing every bit of detail would paralyse even relatively small organisations.
Sure, if you sat everyone down and gave them a briefing on every aspect of everything it would be a pointless waste of time. However, increasing the ease with which information can be pulled down seems fairly simple. If dependencies being complicated is the reason for management setting direction, that seems like a coms problem, the sort of thing that's perhaps best addressed with a project management software than a human manager.
There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks.
Yes there is: if you can't get it done in 1.5 months having already spent 1.5 months working on it, you're not going to get >3 months of start-over work done in a couple weeks. Never mind the boss freaking out at the thought of you abandoning 1.5 months of work, knowing the remaining time isn't enough left to complete it (yes, he knows) much less start over from scratch using completely different tools.
If you had that kind of alleged ambition and talent you wouldn't be in this mess to start with.
It's rarely practical to start over from scratch. For example if other applications use the very same database, you can't just come up with a simpler database schema.
Also in my experience, many business applications aren't vastly complex, they are simply very big and have to handle many, many special cases. That's not something you can redo in a few weeks, no matter how talented and ambitious you are.
I think what you're looking for is some sort of workers' cooperative.
I disagree with the philosophy of your profit distribution. For one, it overstates the value of the first employee and shits over the rest. If the first employee has been at the company ten years and the second nine, it is unlikely that the first employee is twice as valuable as the second employee. For another, I think the elimination of pensions is one of the biggest things wrong with modern corporations.
What I favor is something more like a formalized version of the traditional family farm or business. Everyone gets a share of the business proportional to how much work they put in (years worked, with some minimum to retain your shares after you quit working). Profits are divided among them, and salaries are paid to current workers before profits are calculated.
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...
Yeah, everyone who's actually worked on a software project knows that reading code is harder than writing it, so just understanding the existing code (which is almost certainly under-documented and under-tested) will be more than half the battle.
I would recommend Yourdon's book, "Death March" as mentioned in one of the answers. Although it feels a little dated it is a well reasoned analysis that at worst can give you perspective on a bad situation. When I was in a true Death March project I was surprised that there are so few books on the same issue.
I was recently hired to complete a specific task on a project that sounds similar to this one. On the 2nd day of my involvement and having read through the code a bit, I realized that the task I was hired to complete was the last thing they should be worried about given some of the existential issues in the code and architecture given the deadline.
I voiced some of my concerns to the manager of the project. He got upset and defensive. I quit on the spot.
I had never done anything like that before but I'm glad I did. It could have been rescued but that would have taken a huge personal effort on my part that I didn't foresee being appreciated.
It sounds like this is a 'Kobiashi Maru' Test, which is a no win situation that Starfleet gives to it's cadets.
After this project you will have 5 developers, and several managers that will go on to other projects. I'd say half of those people know what you know, and no one knows how to fix it. If you just work hard on the project one of those developers or managers in years to come might come looking for you to join them on an endeavor. Other than school, I think this is how people develop trust in each other.
If you choose to stay or go, either way you'll build character. It's up to you to decide if you are the sort that digs in and runs to the fire, or the sort that flees to live another day. NOTE: not everyone succeeds that runs towards the fire, but some do, and some consider them heros. Other's consider them fools.
I was fortunate enough to experience this exact kind of death march over a period of around 18 months.
Unless you have the authority to guide the project back on track, there are only so many options available to you:
1: Document your concerns and any problems you've identified. Be objective wherever possible (i.e don't bitch about your co-workers even if the reason the project is failing is because they're fucking it up). Any problems that you've spotted and are worried about, WRITE THEM DOWN and email them to your project manager.
2: Keep a cool head. This is incredibly difficult once endless frustration sets in. Bite your tongue, and don't get personal. You will probably fail from time to time, because knowing that you're going to fail is a horrible, insomnia-inducing feeling, and your patience will almost certainly be tested.
3: Offer solutions. If you think a particular decision is to blame for some aspect of the failure, then document it, what went wrong, and what any alternatives may be.
Unfortunately, in my experience and from what I gather from other people, these kind of things tend to come along with ridiculous company politics and emotions. If your gut feeling is that it's going to fail, then your best approach is to try to raise the alarm as soon as you notice. You may be ignored or brushed aside, but you must document everything you do. Don't raise the concerns in conversation, make sure there is a paper trail.
In my own case, the project failures ultimately led to me and several other developers abandoning the company. The project could have been saved if our concerns were taken into consideration and acted on. We even presented a proof of concept redesign which solved all of the existing problems AND presented new opportunities for growth, and were told that our new design would not see the light of day. Keep in mind that we had working code, schemas, deployment plans, addressed scalability concerns, and even had a development roadmap for the new design. Some battles are un-winnable.
I disagree. If the company in question is large enough having documentation that you were actively trying to avoid disaster, were competent enough to raise concerns and suggest solutions, etc. can be helpful when people come trying to assign blame after the fact.
If the company as a whole will survive the impending train wreck then having evidence of competence, however meager, is certainly useful in many situations short of criminal prosecution.
I'd like to hear from anyone who kept a paper trail which was, in fact, used as so intended. I'd also like a show of hands where it was kept to no avail.
I've been on a lot of projects. Where a paper trail seemed warranted, those who came to assign blame had already chosen their targets without consulting with them first.
Having conversations documented in emails really saved my keister on multiple occasions.
Admittedly on one of those occasions, the effect wasn't immediate -- the manager in question basically rage-quit the conversation. But she put a lot more thought into getting confrontational in future disputes.
(Although I have to clarify that this was a fairly dysfunctional environment (and had been for a while), due to which I figured getting things in writing was the safest choice. In future more cohesive settings, I didn't bother with this as much, as the teams tended to have more integrity.)
> Unless the situation results in criminal prosecution, when the time comes to use that paper trail nobody will care about it.
That's true. Pointing to your paper trail when the shit hits the fan might actually label you as being uncooperative during a critical project; most likely, the manager doing any personnel "cleanup" will be the same that was responsible during the project (line manager vs. project manager). Besides, if a project is doomed, you are not the only one to notice it, so the fact that you pointed it out does not single you out as especially perceptive.
Possibly, but it depends on the project - the level of investment, and the structure of the company itself. If the project's failure is a threat to the company at large, then it's likely that an internal investigation will take place. The paper trail will help defend you.
I'm in a similar situation and the pressure is mostly caused by a lack of management.
I've been appointed project leader halfway the project and I did my homework by reading the Software Project Survival Guide. We are also supposed to work in a scrum system, but on going business causes scrum to be just an extensive time management tool.
We're nearing the deadline and a few things I picked up are:
1) You need to have a hands on approach and come up with solutions yourself. Show a lot of initiative.
2) Have clear roles of who needs to do what.
3) Don't change roles halfway a project, it only causes confusion and someone needs to clean up the mess.
4) Be frank to your business owner about the current reality . You don't want to be the guy, who didn't say anything and pass the deadline. And don't wait too long with saying it.
5) Make it very clear to the business owner, all changes cause a delay. And whatever you do, do not let the business owner decide how long a change will take.
6) Don't fight with the external guys, even if they are trying to run the show. If they start pressing for decisions (framework/system/etc) without a good reason, other than their own comfort, be warned... Get ready for a sticky situation. If you can, stick together with your current team to have some counterbalance.
> 5) Make it very clear to the business owner, all changes cause a delay. And whatever you do, do not let the business owner decide how long a change will take.
This, unfortunately, seems to be a rather large factor when it comes to figuring out why a project failed. Unrealistic expectations are absolute killers.
Plan for the failure. What will things be like when the project fails? How can you best position yourself in the wake of the failure?
Take the steps required to see to your own future.
Do not get caught up in owing anything to your manager or your employer. Your manager transferred a failing project to your group. He is more responsible for you having this failure hang over your head than you are.
To your employer you are simply a resource, not a person. Do not give them the loyalty you would give a deserving person. It will not be reciprocated. In a world where all employees are basically extended freelancers, you need to put yourself first.
I found it interesting that his list of reasons why the project might fail sounds like pretty much every project I ever saw in the 1990s and early 2000s. Although some of them are definitely bad signs, some are just par for the course in organisations that arent big on software development. I wouldn't say its a guaranteed failure. He might just be unfamiliar with what real-world projects are like in an enterprisey environment.
- deadline approaching many of the must-have features are not finished.
- Application is unstable and very difficult to use.
- System is very convoluted, code very hard to understand, very difficult to change.
- complex relational database (100+ tables).
- Unclear leadership, the manager responds to every new information with significant change in plans.
- Almost no automated tests or unit test.
- Heavily depends on other systems, but no integration tests yet.
Perhaps upper management will fudge and extend the deadline (rather than be embarrassed) and the project will limp towards some sort of closure that everyone can just about accept.
Enterprise software development. Plan, plan, plan, plan, execute, fail, extend, extend, extend, deliver. The PMs job is to get the project extended from day 1 because nothing was planned out correctly.
Thing is... a lot of projects seem this way when you're in the thick of it, but towards the end the mess can untangle itself and provide a useful tool/product for someone.
> Application is unstable and very difficult to use.
Could be that there are a couple of "killer bugs", fix them and it might not seem so bad. Difficult to use is also subjective, people get use to stuff.
> System is very convoluted, code very hard to understand, very difficult to change.
This could be "I don't understand the code, or know how to change it".
> Datamodel is too driven by a complex relational database (100+ tables).
OK, this one I can't defend :-P
> Unclear leadership, the manager responds to every new information with significant change in plans.
Well, if the plans are adding new features, these should go to the "nice to have" list. If it's "we need to rewrite this" then that's not good.
> Almost no automated tests or unit test.
No autowhatnow? :-D I don't think a project is necessarily "headed for failure" just because there are no automated/unit tests.
> Heavily depends on other systems, but no integration tests yet.
Yet! That's good, there's still time to test this before shipping.
> 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.
Aha! The root of the problem "I don't feel comfortable with other people's code"?
Interesting take, in fact recently I was working on a project that I was convinced was going to be a huge mess but in the end out clients seemed fairly happy with it, and understanding on inevitable roadbumps.
> OK, this one I can't defend :-P
I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data?
> I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data?
Maybe it's my lack of imagination, but I can't think how you'd create a design with hundreds of tables by hand - it would surely involve generating tables from some other source. For different types of data I'd lean more for a javascripty-style meta-table with key-values, since I bet all that different type of data wouldn't lend itself well to relations.
Do not understand someone else code, is a valid issue, if the project was development for a few month. Then team got switched around this is a huge RED flag by itself. Big question is why this happened. Staring at a large code base with 1.5month to finish it, no tests, probably zero documentation and manager who used to manage the previous team.. RUN not walk away from this
What? That is the one thing that stands out as being an obvious "this person has no idea what they are doing" red flag. It doesn't need defended. Having 100 tables is not a problem, in any way. Thinking that having a correct database is bad speaks very poorly for the quality of the developer in question.
To come at this from a different angle, throw in some random thoughts, play devils advocate and all that....
What is the definition of "fail"?
Maybe, given that the project is a hand me down, just barely working is good enough to the client. Maybe there is accepted scope for an over run.
How do you know it will fail?
Given my questioning of what a fail is, clearly knowing it will fail is up for grabs.
Will the OP's negativity cause it to fail?
This bothers me. An employee who is dooming a project is in danger of dragging the whole thing down.
Perhaps the OP is prejudging things too much?
If the OP "knows" it will fail, the likely hood is that so does every one else.
What seems odd to me is the OP's seemingly isolated position, where it looks like he doesn't get to talk to his co-workers or management. If he knows it will fail, then surely so do his co-workers. Management must also know its not progressing. But, he seems unable to discuss this with any of them, even casually. If this is the case, then my concern would be for the future of the whole company.
think about possible outcomes after it will become clear that it failed and think how to adopt to this situation as it's clear already that it won't be easy go
Ask for proper priorization and focus on completing as many features as possible, one after the other. It's far easier to build one feature while maintaining multiple others than to build multiple features at the same time, especially with a lot of legacy code.
If they can't prioritize at this point, insist. Point out that in this situation where everyone is stressed for all the possible reasons, with proper priorization you're far, far more efficient than without. For all you know, you can be done with individual parts within hours if you can safely scratch other, less important features that are also in development, only to take them back up and running the next day as they become in turn the highest priority.
If they still can't prioritize at this point, prioritize yourself.
If you don't know it already, find a customer relationship contact and ask for one of the main timesinks for the users that the product is supposed to solve. Let him describe to you the usecase, or let him point it out to you in the functional specs, and do it from start to finish. This one has to work, and that's your new goal in life. Be proud when it's completed, your grunt work is done. Show it to your boss, and let him know that's what requires integration testing right now. Your new goal in life now, is to make sure that this usecase is viable in production. You will find new issues, encounter new problems, but these are better problems because they are not entirely up to your team, they are the kind of problems that a lot more people can understand since they are not purely dev issues. You will get a ton more help at this point, a ton more understanding, a ton more visibility on the project, and management will be able to make a much more informed decision about the so-called deadline.
The key to proper "failing" of a project is to never let it be a complete failure. Finish a usecase and deliver it, so that at least someone could get added value from what the project committed. This is how the customer & management should prioritize for you: make sure that there are usecases where the product is fully functional from start to finish.
162 comments
[ 2.3 ms ] story [ 209 ms ] threadThen (assuming you want to keep working there, as the author seems to) make it clear that if they still want to go ahead then you are fully committed to helping them to the best of your abilities.
But a project in as bad a state as described? Get another job.
Sometimes the problem is that the issues are communicated, but not the severity. So, you might raise that the database is too complex with 100+ tables, but if the manager does not have an intuitive sense for the consequences of that problem, it might not register as a project-destroying issue. That becomes the disconnect later, and when things go pear-shaped, these disconnects become issues of contention.
The worst thing you can do is to raise these issues quietly and just keep trucking, as if you've done your job, and that's that. [wiping hands gesture] If management doesn't realize that the project is headed for disaster, that's on you (and the others on the team).
But, if you're able to convey the severity of these issues clearly and professionally, the conversation might turn to what can get done in the near term that would be valuable. Or, to the point of other commenters, there might be other factors at play, and the manager might want you to keep trucking anyway. In this case, provided you have been clear about the risks and threats, you really have done your job.
As a parting thought, you could also raise an issue around "what type of company" you want to work for. Perhaps if they need to rock out a rough proof of concept with no automated testing (or any testing!), that's one thing, but I wouldn't want to work at a company that doesn't take testing seriously. So perhaps if this is a manic sprint to prove something, we can all get on board with cowboy coding, but once the dust settles, it will take x amount of time to shore up the work with xyz types of tests. If they aren't on board with taking their medicine and putting the right tests in place, then that might be reason to depart even if the proof of concept succeeds.
Most organizations operate (and should operate) according to what the top-level decides should happen. If the top-level defaults on that responsibility, then chaos will ensue.
In those cases a value judgment of the process is a value judgment of the organization, and most astute managers realize it sometimes before the "innocent" (i.e., socially naive on organizational dynamics) system builder guy realizes it.
If both of those are part of the problem (don't worry! All is well!), rather than realistic (we know there are serious problems here but we think there's a chance/we'd like to try anyway), then it's time to think about the systemic problems and consider finding yourself a new job (IMHO).
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 thing to do would be to make any choice in between these two.
a.) If you're sure there's a path to success and you're invested in getting there, do whatever you can to achieve that goal--understanding that one of the possible outcomes is to be told to pack your things and leave. Now. The likelihood of this outcome obviously depends on the exact situation.
b.) Accept that things are not going to end well. Do your job, keep your head down, and start seeking alternatives ex post haste. In some situations, seeking alternatives ex post haste may, in fact, involve fleeing (especially in a short time horizon such as this one) but I've certainly been in situations where the writing was more or less on the wall but more in the vein of a long ponderous collapse.
Fresh gazelle is delicious. Try not to overeat. There's a whole heard, and the pride will catch another one tomorrow. It's all a matter of perspective.
I would disagree there.
A good manager might take the situation well - they may have been misinformed by others and think things are far better than they are.
If that isn't the case there may be the option of going above the managers head, though this has to be considered very carefully. In may case once it went rather well: the person above me had grossly misreported things above him. We are still dealing with some of the legacy of that period, but getting through it (and that person is no longer here). Of course depending on local politics this could go very badly, so I'll repeat: consider this sort of action very very carefully before taking the step.
In my case saying "things have been X bad for a while, if things don't change either we are going to fail badly very soon or I'm going to burn out inside a couple of months" got the message across (it turns out an honest assessment was appreciated and that not losing some of us through walk out or burn out was important enough to warrant rearranging some plans and expectations). Of course I'm lucky: the Powers That Be here are sensible and I've been here over a decade & proven myself a good few times over so my word carries some weight - a relative new-starter under a less receptive hierarchy would not fair so well.
If there really are no options for plan A for whatever reason, no end of time/overtime will fix the problem and there is no way the management can be made to appreciate the scale of the problem, that leaves plan B: get ready to jump ship.
That being said, decisions like reversing project directions or pivoting are usually huge multi-party decisions not up to a single person (unless it gets escalated to the very very top).
A politically savvy employee would be able to make it work. Albeit, after saving the project (or making an admirable effort that catches everyone's eye), that employee would probably be marked by management for a management role. ;)
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 thinking. If a failed project is inextricably linked to your personal well-being, you're in the wrong business.
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.
Exactly. The world is pretty small and you shouldn't step on somebody's toes unless you absolutely don't see another way out.
The sensitive thing to do here, is to make sure you've got your ass covered and if this is a persisting problem or you feel like you can't work there anymore, then you quit after the current job is done. And hopefully you can leave with a good recommendation.
Like @angdis said elsewhere in this discussion, projects "fail" all the time, but the OP is talking about a specific kind of failure. Notice how many commenters mention "finger-pointing" and "paper trail". When you find yourself in a situation where that becomes important, it's time to consider leaving and it's always better to leave on your own terms.
Unless you're deeply invested in that project or that company, it's usually better to start looking for a place where projects fail more gracefully than this.
It's very frequent that "Team A" works on a software product and gets some of it done. Then the work gets sent to "Team B".
"Team B" usually finds many deficiencies at work in the code. For instance, people frequently bungle the design of 10-table databases, so perhaps there are dragons in the 100s of tables.
"Team B" sometimes delivers the product, usually late. Sometimes it doesn't.
That's life. The Gartner Group says that 2/3 of all IT projects fail and I think that's about par for the course.
First: why is that? Are there good reasons for this, and does this happen for those reasons?
Now, knowing nothing about the company, if I learn that every other project suffer a change of team before going into maintenance (officially and actually), then it's substantial evidence that something is wrong with management.
Whether one should quit of course depends on how wrong.
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.
IMHO the best thing to do is to express your concerns and from there on just do your job without investing any extra effort. You can't be reluctant cause this will be received as not caring, neither invest the extra effort because usually the reason projects fail is not incompetent programmers but wrong specifications. Let someone else take the blame.
On the other hand, it sounds like a depressing situation to be in, so I'd prefer your option (b).
The worst thing about staying to turn things around is that often the failure is set up from the beginning by those in leadership. Your reward for working your ass off to make the project succeed is probably going to be to make someone look good who was responsible for digging the hole that you helped to pull everything out of.
Unless the game board is set up so that you benefit heavily from your hard work (equity, bonuses rewarding the risk and effort) - there's little upside to killing yourself besides some opportunity for personal growth.
But even assuming this, choice (b) is only local optimization. One could consider instead doing (c) - to try as hard as possible to convince the management to shut down that project ASAP, and thus saving the company many man-hours of wasted work. The global gain will be much greater then. Of course if management is stubborn and you're still sure the project will fail, then you're back to option (b).
To get high performance without burnout it is necessary to switch from complete engagement to complete disengagement every few hours.
The Serenity Prayer from Alcoholics Anonymous is asking for the right thing here, even if you aren't religious.
"God grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference."
It's great to be passionate but it's also important to be detached about things you can't control.
One detail that is missing from this story is the nature of the deadline. Lateness is endemic in software development, and successful projects often get delivered years after they were promised. Late doesn't necessarily mean "failed."
You can't go wrong learning more about project management so you can have a more correct understanding of the situation.
Whatever you do, keep your honor. Being ambiguous about wanting the job gives you the unique freedom to refuse any order that you truly don't want to carry out.
This is fantastic advice, and one of the main things I tried to drill into my team (when I had one), with fairly mixed success. It's very hard to convince people who are attached to a project that they should at any point just go "meh, what can you do?" but sometimes that really is your only option. Advice for any startups in this situation - if you really have to impose some awful condition on your workers, make sure you explain it fully to them. It's easier to accept something you don't like being imposed on you if you understand it, even though you don't agree with the reasoning.
Another really tricky fine line is, having done this a couple of times, to then stop people going "meh, screw it" when they really can control the outcome, but just don't feel like it for whatever reason.
Even if one of us calls it right, which is sheer luck with so little information, the OP clearly has most to gain from experience.
That is the only way to learn to correctly identify problems, and perhaps more importantly, what is the best way to deal with for you personally.
You are the lion and the resources of the company are the gazelle. It's time to feast!
It's really a good time to:
1) ask for a raise for more "effort"
2) ask for more budget
3) that new computer they've been holding out on.
Ya, you can ditch that 17" laptop from 2006. ;) Just ask!
We know that throwing resources into the game this late doesn't work, but it's good to have that extra budget for later just in case you wildly do succeed.
Frankly this sounds like the sort of environment where introducing scrum would be a big step forward. As the developer, knowing a good scrum consultant to introduce to the company might be a good move, once the fail happens.
Since it's only 6 weeks to the deadline it is probably worth pitching in and trying to make it work. If failure is going to be a big deal then you'll all be looking for jobs anyway. Alternatively it might turn out that the deadline was not so crucial and you will be able to sort out the mess.
Always remember that rats are first to desert a sinking ship - you don't want to end up with being labelled as such.
Being upset at being labeled a "rat" means you're alive.
This pervasive "don't raise concerns or you'll get targeted" is all too often WHY projects fail: people keep telling the decision makers "everything is fine, we'll deliver on time" while mumbling "ain't no way this thing's gonna make it" in dark corners, leaving those with the power to do something about it unaware of the problem approaching, and looking for heads to roll when it does. If you're going to be punished for speaking up (objectively, professionally) then it's time to get out of a toxic environment.
People will probably lose jobs. Sometimes that will happen based on seniority and sometimes it's just random. Sometimes, that will happens to the PITAs who spoke up and happened to be right. You don't want to be a PITA. PITAs become blame dumpsters even when they were right, because enough people hate them and no one will defend them. You're not the only one who knows that the project is fucked. Just keep your mouth shut about the fact.
There's something I call the Welch Effect, which is that the people most likely to be laid off are junior/least-established members of macroscopically underperforming teams (who had nothing to do with its underperformance, because they had no power). Managers are sometimes sympathetic to the Welch Effect and will set a "no infanticide" rule, but not if you're a PITA.
Keep your head down, do good work when work is asked of you, and start planning for your next move. Start networking and searching and building skills now, not when you need to.
If you lose your job, don't take it personally. It's not your fault, and if you tell the story in the right way, no one will hold it against you. These things happen to good developers, especially early in the careers, all the time. Most projects fail. It's not like school where something has to be going wrong to fail a course, because only 5-10% get F's. It's probably 50-75% of software projects that fail.
DO voice your opinion and professional expertise.
DO make recommendations as to how to salvage or improve a project. Not doing so will not get you anywhere.
If the project is doomed to failure, being a PITA means you're more likely to get fired while silently working out a transfer or next gig has only upside.
If you're a developer, you often can help save projects that are failing because they were poorly outsourced, or handed to the wrong team, or technically flawed. You usually can't save projects that are failing because management never really believed in them, or that are caught in crossfire between conflicting factions on the corporate board, or that have never been funded/resourced at the levels required for success.
This is probably the most important piece of advice in the whole discussion. Getting all worked up about someone else's responsibility.
Another interesting side issue not explored yet... I believe its a distorting factor that he has semi-privileged information and opinions about his own area of expertise. If he had semi-privileged information and opinions about the supply of packing tape in the shipping department, or the technology level of the forklift battery charger in the warehouse, he'd wisely be advised to stick to casual careful gossip unless its human safety critical, aka just do his job... at work. At home, if certain that the battery charger is going to cause irreparable financial harm, sure, go update that resume... just keep it at home.
One of the tracks of the discussion here and on Stack Exchange is to elevate the situation to a plane requiring moral decisions. And it just ain't so. A line worker does not have fiduciary responsibility, and as you rightly point out, this doesn't entail issues of life safety, public health, or economic exploitation.
It's just normal muddling through.
The biggest hazard to the person posting the question on StackOverflow is erroneously assuming they are the smartest person in the room, or in its most common form, that everyone else is an idiot. Trains are big loud whistling contraptions with bright lights. Unless distracted, few people fail to see and hear them coming.
The last project I worked on was something essential to Lucent's survival as an independent entity. Many of you have heard of sophisticated telephone switches, like the Western Electric (AT&T) then Lucent 5ESS (http://en.wikipedia.org/wiki/5ESS), a really impressive monster that's truly 5 9's reliable (or it genuinely tried to be and by and large made the grade).
The new way of doing this is (or was as of 2001) to split the functions of such a switch into a Media Gateway Controller AKA Call Agent e.g. the Lucent Softswitch, which understands things like billing, and a Media Controller which does the actual work of connecting A to B and converting as needed (e.g. POTS to VoIP). There's even a dual ITU/IETF protocol for communications between the two, Megaco AKA H.248 AKA RFC 2805.
It should be obvious that being able to offer a complete solution was essential for Lucent's future, as conventional switch sales were at least projected to plummet, and my group was part of effort to create the other half the company needed, the Media Controller. Which was a challenging thing, including that true 5 9s reliability requirement (just say no to hard disks, I was among other things the database guy in testing, and the operational database lead and I had to vet and sign off on each other's designs (mine was a data warehouse approach for storing fine grained events generated by the test system, Oracle was real fun for that sort of thing and we had a 106,000 seat license (!) from them, although headcount was going down to 35,000), and I was personally responsible for testing his system).
ADDED: going off the Yourdon Death March chart included in OP comments, this was a "mission impossible" project, high happiness (fun, challenging project), at least a decent chance of success initially (e.g. we were working with the 5ESS people, who taught us a lot of neat stuff about real 5 9s.)
Anyway, at a certain point, completely insanely a company wide headcount cull was applied to this effort, and I'm pretty sure it was sufficient to kill the project (my testing area was gutted, going from "maybe, just maybe we can get this work done in time" to one engineer plus a little outside help, with one manager, a failed programmer so she wasn't of much if any help).
One of the things that really stood out was the layoff of a pretty famous person in the company, a jack of all trades who e.g. had the energy and skill to take the chosen (Linux based) RTOS from the vendor and get it up and running in our environments, kick the tires and minimally validate it, etc. Don't know if he was a PITA like I was in part, but it's hard to imagine he wasn't at least a bit, he was the sort of guy who was in a position to say "This won't work because I just tried it".
The managers flaunted his layoff like a badge of honor, an implicit "If this guy can get fired no one is safe", and blatantly lied about the grounds. They claimed he was "inflexible" about what he'd work on, when it was a very visible matter of written record that he'd very productively work on just about anything. I never even talked to this guy, I just learned of his background and merits from the written progress reports and mention of him in an occasional conference call meeting, he was perhaps the most visible "exceptional" employee in this make or break project.
And yet he was purged.
(As was I, although that was by abuse from an envious boss and may not have even been part of the headcount cull; while I wasn't hardly so visible, I was the only serious software engineer on the testing effort, and there was no way the company could build the new test system without someone of my caliber. And you'll never create a true 5 9s system without serious testing.)
And as many of you know, the bottom line is that Lucent was bought by Alcetel and is a shade of its form...
http://arstechnica.com/tech-policy/2013/05/newegg-nukes-corp...
"Sleazy" is not, I gather, a word that typically used to be associated with Alcatel, and certainly not the pre-breakup AT&T.
If you're going to stay around pick something that you think is the most important function/feature and make sure that it is amazing. There is almost always some smart people around and some new things to learn.
Taking responsibility for things over which you have no authority will make you miserable and crazy. Find out where your authority stretches and make the most of that area leads to amazing developments. I can predict that the education system will continue to suck tomorrow and there isn't much I can do about it but tutoring a few students at my local school can really make a difference in their lives.
1) You are wrong and paranoid. The project will be delivered with some hurdles but will not be catastrophic at all. Try to make sure that your concerns are clearly defined. Contrary to most people here advise: don't try to be the nice guy by being subtle. Be polite but be also confronting.
2) You are right and you will not be able to change the situation. In this case, I would choose the easy way and leave for another job. Watch out for the stockholm syndrome: there are other companies where you can enjoy your work. Don't feel to much sympathy for the current situation or be afraid of uncertainties that come with leaving.
But not communicating is not going to help anyone, unless you feel confident that you can get the project back into shape.
So the deadline is missed. It happens. The stakeholders need to be prepared and they need to have runway to take action. Finding out in the final week then being asked to train up 10 new contractors is not going to work. Managers know that it doesn't work, but more often than not they feel that is the easiest way to help.
You shouldn't give up your personal time unless you feel there is some reward, otherwise you will just feel bitter and leave the company in the next crisis. I gave up a lot of personal time to save a project. I did it for my own credibility and passion, but money, time off in lieu and promotion are the rewards that keep employees. I got one week off (after giving 5 weeks of personal time), and £250 of vouchers (but only if during this crisis, I worked a Saturday on someone elses project). I left that job within 12 months.
If anything else, you'll learn the experience of what works and does during crunch time.
I hope future historians will be astonished that all of us chose to accept such insanity without doing anything to change it.
Thought experiment: There's nothing stopping this developer from taking the requirements of the project and developing a solution from the ground-up in their language of choice over the course of a couple weeks. The project has been in development for 1.5 months and has 1.5 months to go before the deadline. Their current solution apparently involves relying on a relational database as some kind of programming language or configuration system (100+ tables). There's a good chance that a developer with ambition and talent could singlehandedly deliver a superior solution within a short timeframe.
So what stops the developer from executing? Primarily his own (fully justified) fear of negative consequences. But the only reason his fears are justified are because of structural problems in how companies operate today: managers are expected to drive the direction of the project and are given the authority to do so, and the authority to fire anyone who won't go along with the manager's vision. That makes it impossible for a developer to make sweeping changes and be perceived as doing anything but challenging the manager's authority. But it's not about authority. It's about the customer. It's about making good products. Yet the environment is set up so that the developer concludes that it's entirely justified to be afraid; to sit quietly and do nothing. And it's precisely this collective fear that drives this sort of degeneration within companies.
There has to be something better. I want to try to build something better. Some new way of thinking about how to build a modern software business. Profit sharing, maybe. It might be possible to set up a company such that it could pay its employees a percentage of the profits. The first employee would get 15%. The next employee would get 7.5%, and the next 3.75%, and so on. Then as the company makes profit, that profit is continually paid out proportionally to each employee.
That system has all sorts of flaws, though. One example: an employee should only be getting a percentage of profits while they're at the company. They should be getting their full percentage on day one, and should give up their percentage on the day they leave the company. But I can't think of any mechanism which would actually let a corporation pay out like that. If you tried to pay out profit via dividends, then you'd have to allocate the percentages using stock, and employees don't typically get stock up front on day one -- it takes several years to vest -- and they don't lose it when they leave the company. So profit sharing via dividends wouldn't work.
The idea is to provide an incentive to employees for projects to be useful to customers. There's currently no incentive. Employees are generally expected to play the politics/career game in order to secure a safe future for themselves. I guarantee you that if the employees at OP's company had been given some percentage of future profits, then they would currently be revolting and calling out that manager's behavior and incompetence.
These are famous last words. So often I see people go off on the weekend to code a replacement for a legacy system, come back with a good demo, but not realize that they did 2.5% of the work that was responsible for 25% of the functionality.
Complex systems tend to have many written and unwritten requirements that aren't captured in their clones.
Anyway, I would not look at 100+ relational tables as being a bad practice in and of itself. I've worked on plenty of systems of this complexity, and it's really no problem at all if you're systematic. You need to have a machine-readable data dictionary and you can't be writing all your SQL by hand.
Well, I've done it. I've developed complete solutions to business problems that the company was trying to solve. I did it without waiting for permission or for my design to be approved, and I did it only after I fully researched and understood the problem space and the future goals of the company. Then I made sure the design took into account all of those future contingencies without being rigorously bound by them, i.e. flexible and not a hindrance when the business goals change in the future -- which they always do. At the most recent company I worked for (a massive corporation) the system is expected to be in production for the next 3 years at a minimum. I did the first 90% of the work in two months, then the other 90% of the work in another month or so. The fourth month was spent primarily on training, documentation, and meetings.
Competence exists. The managers are simply given the authority to squander it or to perceive it as a threat and fire them. I was lucky enough to have a manager who was receptive to me overstepping my bounds as a contractor. I made decisions (such as making Redis a core requirement of my design) before asking permission or waiting for approval. I presented a demo of an early version of it to my manager at the end of my first week, and thankfully he was both surprised and happy about it. (40x improvements to the existing infrastructure tend to elicit that reaction.) But most large corporations, and even many small ones, aren't like that at all. You'd be fired for overstepping your boundaries, whether or not you were capable of making a difference to the bottom line. It's up to the manager, and that is a wholly backwards way of running a modern software corporation.
For software companies, there has got to be a better way than the existing approach. At the very least, the concept of a "manager" should be divided into two people: a manager and a producer. The producer's role is to drive their project's goals. The manager's role is to ensure that the employees are happy and to deal with roadblocks (such as if an employee needs to purchase a third-party tool). The manager has the authority to fire people; the producer does not. The manager's goal is to look after the team, not the project. And neither of them can tell an employee what to do. The employees are given tasks to complete, not steps to complete, and then trusted to complete that task. The employee is trusted not to accept tasks which he/she feels are too ambitious for the producer's timeline. So the producer can only barter with the employees, not demand from them.
I know of a massive videogame company (not Valve) which operates that way, and it's the reason they're currently the industry leader in their genre even though they've grown exponentially as a company over the past four years, both in employee count and customer count. So it absolutely worked for them, and I'm willing to bet that it would work in a lot of software companies. I want to prove that it works.
Maybe I've been lucky, but in nearly a decade of technology work I have never been penalized for 'overstepping my bounds' by improving something important. I think improving important things is within everyone's bounds, tbh.
I can practically guarantee (and the OP strongly implies it) that the problem with this project is not that it is hard to implement, but that its requirements are unspecified.
Rewriting it in a fancy feel-good language changes exactly nothing and should be treated as an act of sabotage, because it is exactly that.
When I was younger, I would've actually done this. As I got older i learned some things, and one of those things is that 20% of the work will take about 80% of the time. I'm sure he could take a week or two, develop a kick ass demo that demonstrates a working concept... but it won't make the project finish sooner. Rewriting existing code that's hard to work with is essentially defaulting on technical debt. If he skips essential things like writing a proper design doc (documents are a really good way i've learned to communicate with your team, don't skip them!) if he doesn't have good code coverage, then he's simply taking out a new loan.
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 the strategies that were in place for future functionality, that placed very different requirements on the platform. As a result his solution was of no value to us.
There was serious discussion about terminating said developer because of the amount of time he'd wasted on that, and the discord it created in the team when he tried to push his "solution" as an alternative to the existing system.
Often the direction is set by managers for good reason: Sharing every bit of detail would paralyse even relatively small organisations.
That's not to say that skunkwork projects like that can't work or be beneficial, but in my experience the odds are high that they will overlook something important. Before doing something like that, the developer should at least put in a lot of effort to try to learn exactly why the current project is the way it is.
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
In other words, he pissed management off. He busted his as off trying to improve the product and was rewarded by being treated like shit. It really sounds more like he was railroaded by company politics by stepping on the wrong peoples toes.
No, he wasted valuable time and company resources attempting to do something that wasn't needed, or asked for, and provided no value (arguably negative value) to his team in doing so. Of course people work hard and aren't rewarded for it, but it sounds like it's the case here that this cowboy was trying to outwit the system and ended up hurting the team a lot with his irresponsibility.
In one memorable case, the developer missed some pretty important requirements that mattered a lot to management but did not matter to him. The developer certainly felt that he was railroaded by politics. But I, as an independent observer at the same level, could easily see that management was right to want what they wanted, and that the developer was too emotionally invested to see what he was missing.
Same company, same team, same developer, a different project, not too long earlier. He went off and developed something that really did meet the needs we had, and got rewarded for it. The difference is that he actually understood the requirements and nailed them.
Drive, ambition, technical chops, and an unwillingness to listen first can get a lot done, very quickly. The same characteristics can create a lot of conflict very quickly as well. It is hit or miss which happens in any particular case. And on the misses, management is easy to blame but they are not really to blame.
He busted his ass to deliver something un-asked for that didn't meet more than maybe 5% of our requirements and didn't improve the product in any way, rather than doing the job he was paid to do, because he decided he knew a better solution without knowing or understanding what the full requirements were.
Had he come to me and asked if he could do an experiment to see if he could rebuild part of the system simpler, we would have discussed the idea with him. If he gave me reason to believe he could meet the full requirements rather than what he thought the requirements were, we would certainly have entertained the idea of giving him time to prototype something.
But he didn't. He made a ton of assumptions that were mostly wrong about what the system needed to do, because he was not privy to e.g. the strategy discussions the board and executive team had, and the discussions we'd had with investors.
That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots. While doubtless sometimes they are, a lot of the time they simply have more information than you.
The situation you're describing is a management failure of epic proportions. Failed to communicate future planned features to dev team. Failed to exploit someones willingness to take responsibility. Failed to get input from the programmers (obviously at least one of them thought the code base was a mess).
Oh, and hiring someone who believed making a good product was more important than following chain of command. Big mistake there.
> That's my caution to people who assume everything they don't understand about what they're working on means the people running the projects are idiots.
Even construction workers always knows what they are working on and why their work is important. If management is unable to communicate to the developers what purpose their work serves to the company then that is incompetent beyond belief.
At some point, especially when dealing with senior developers in a fast moving startup environment, you have to assume you're dealing with reasonably responsible engineers who understands that if something doesn't make sense to them immediately, their first instinct should not be "I can rewrite this component that isn't remotely part of my job in a few weeks, no need to ask anyone", but rather to ask "what am I missing? Please explain this to me".
I've personally come across many cases where something looked trivial to do better, and occasionally I'm right, but I'm also humble enough to go ask the questions before I put aside the work I've been asked to do and go off to rewrite something else.
Sure, if you sat everyone down and gave them a briefing on every aspect of everything it would be a pointless waste of time. However, increasing the ease with which information can be pulled down seems fairly simple. If dependencies being complicated is the reason for management setting direction, that seems like a coms problem, the sort of thing that's perhaps best addressed with a project management software than a human manager.
Yes there is: if you can't get it done in 1.5 months having already spent 1.5 months working on it, you're not going to get >3 months of start-over work done in a couple weeks. Never mind the boss freaking out at the thought of you abandoning 1.5 months of work, knowing the remaining time isn't enough left to complete it (yes, he knows) much less start over from scratch using completely different tools.
If you had that kind of alleged ambition and talent you wouldn't be in this mess to start with.
Also in my experience, many business applications aren't vastly complex, they are simply very big and have to handle many, many special cases. That's not something you can redo in a few weeks, no matter how talented and ambitious you are.
I disagree with the philosophy of your profit distribution. For one, it overstates the value of the first employee and shits over the rest. If the first employee has been at the company ten years and the second nine, it is unlikely that the first employee is twice as valuable as the second employee. For another, I think the elimination of pensions is one of the biggest things wrong with modern corporations.
What I favor is something more like a formalized version of the traditional family farm or business. Everyone gets a share of the business proportional to how much work they put in (years worked, with some minimum to retain your shares after you quit working). Profits are divided among them, and salaries are paid to current workers before profits are calculated.
That seems like a serious red flag to me. That manager's career is probably headed nowhere fast...
I voiced some of my concerns to the manager of the project. He got upset and defensive. I quit on the spot.
I had never done anything like that before but I'm glad I did. It could have been rescued but that would have taken a huge personal effort on my part that I didn't foresee being appreciated.
After this project you will have 5 developers, and several managers that will go on to other projects. I'd say half of those people know what you know, and no one knows how to fix it. If you just work hard on the project one of those developers or managers in years to come might come looking for you to join them on an endeavor. Other than school, I think this is how people develop trust in each other.
If you choose to stay or go, either way you'll build character. It's up to you to decide if you are the sort that digs in and runs to the fire, or the sort that flees to live another day. NOTE: not everyone succeeds that runs towards the fire, but some do, and some consider them heros. Other's consider them fools.
Unless you have the authority to guide the project back on track, there are only so many options available to you:
1: Document your concerns and any problems you've identified. Be objective wherever possible (i.e don't bitch about your co-workers even if the reason the project is failing is because they're fucking it up). Any problems that you've spotted and are worried about, WRITE THEM DOWN and email them to your project manager.
2: Keep a cool head. This is incredibly difficult once endless frustration sets in. Bite your tongue, and don't get personal. You will probably fail from time to time, because knowing that you're going to fail is a horrible, insomnia-inducing feeling, and your patience will almost certainly be tested.
3: Offer solutions. If you think a particular decision is to blame for some aspect of the failure, then document it, what went wrong, and what any alternatives may be.
Unfortunately, in my experience and from what I gather from other people, these kind of things tend to come along with ridiculous company politics and emotions. If your gut feeling is that it's going to fail, then your best approach is to try to raise the alarm as soon as you notice. You may be ignored or brushed aside, but you must document everything you do. Don't raise the concerns in conversation, make sure there is a paper trail.
In my own case, the project failures ultimately led to me and several other developers abandoning the company. The project could have been saved if our concerns were taken into consideration and acted on. We even presented a proof of concept redesign which solved all of the existing problems AND presented new opportunities for growth, and were told that our new design would not see the light of day. Keep in mind that we had working code, schemas, deployment plans, addressed scalability concerns, and even had a development roadmap for the new design. Some battles are un-winnable.
Unless the situation results in criminal prosecution, when the time comes to use that paper trail nobody will care about it.
I disagree. If the company in question is large enough having documentation that you were actively trying to avoid disaster, were competent enough to raise concerns and suggest solutions, etc. can be helpful when people come trying to assign blame after the fact.
If the company as a whole will survive the impending train wreck then having evidence of competence, however meager, is certainly useful in many situations short of criminal prosecution.
I've been on a lot of projects. Where a paper trail seemed warranted, those who came to assign blame had already chosen their targets without consulting with them first.
Admittedly on one of those occasions, the effect wasn't immediate -- the manager in question basically rage-quit the conversation. But she put a lot more thought into getting confrontational in future disputes.
(Although I have to clarify that this was a fairly dysfunctional environment (and had been for a while), due to which I figured getting things in writing was the safest choice. In future more cohesive settings, I didn't bother with this as much, as the teams tended to have more integrity.)
That's true. Pointing to your paper trail when the shit hits the fan might actually label you as being uncooperative during a critical project; most likely, the manager doing any personnel "cleanup" will be the same that was responsible during the project (line manager vs. project manager). Besides, if a project is doomed, you are not the only one to notice it, so the fact that you pointed it out does not single you out as especially perceptive.
I'm in a similar situation and the pressure is mostly caused by a lack of management.
I've been appointed project leader halfway the project and I did my homework by reading the Software Project Survival Guide. We are also supposed to work in a scrum system, but on going business causes scrum to be just an extensive time management tool.
We're nearing the deadline and a few things I picked up are:
1) You need to have a hands on approach and come up with solutions yourself. Show a lot of initiative.
2) Have clear roles of who needs to do what.
3) Don't change roles halfway a project, it only causes confusion and someone needs to clean up the mess.
4) Be frank to your business owner about the current reality . You don't want to be the guy, who didn't say anything and pass the deadline. And don't wait too long with saying it.
5) Make it very clear to the business owner, all changes cause a delay. And whatever you do, do not let the business owner decide how long a change will take.
6) Don't fight with the external guys, even if they are trying to run the show. If they start pressing for decisions (framework/system/etc) without a good reason, other than their own comfort, be warned... Get ready for a sticky situation. If you can, stick together with your current team to have some counterbalance.
This, unfortunately, seems to be a rather large factor when it comes to figuring out why a project failed. Unrealistic expectations are absolute killers.
Take the steps required to see to your own future.
Do not get caught up in owing anything to your manager or your employer. Your manager transferred a failing project to your group. He is more responsible for you having this failure hang over your head than you are.
To your employer you are simply a resource, not a person. Do not give them the loyalty you would give a deserving person. It will not be reciprocated. In a world where all employees are basically extended freelancers, you need to put yourself first.
Failing to plan is planning to fail.
- deadline approaching many of the must-have features are not finished.
- Application is unstable and very difficult to use.
- System is very convoluted, code very hard to understand, very difficult to change.
- complex relational database (100+ tables).
- Unclear leadership, the manager responds to every new information with significant change in plans.
- Almost no automated tests or unit test.
- Heavily depends on other systems, but no integration tests yet.
Perhaps upper management will fudge and extend the deadline (rather than be embarrassed) and the project will limp towards some sort of closure that everyone can just about accept.
> Application is unstable and very difficult to use.
Could be that there are a couple of "killer bugs", fix them and it might not seem so bad. Difficult to use is also subjective, people get use to stuff.
> System is very convoluted, code very hard to understand, very difficult to change.
This could be "I don't understand the code, or know how to change it".
> Datamodel is too driven by a complex relational database (100+ tables).
OK, this one I can't defend :-P
> Unclear leadership, the manager responds to every new information with significant change in plans.
Well, if the plans are adding new features, these should go to the "nice to have" list. If it's "we need to rewrite this" then that's not good.
> Almost no automated tests or unit test.
No autowhatnow? :-D I don't think a project is necessarily "headed for failure" just because there are no automated/unit tests.
> Heavily depends on other systems, but no integration tests yet.
Yet! That's good, there's still time to test this before shipping.
> 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.
Aha! The root of the problem "I don't feel comfortable with other people's code"?
> OK, this one I can't defend :-P
I'm curious as to the why of this? Surely some applications just require a lot of tables as they deal with a lot of [different types of] data?
Maybe it's my lack of imagination, but I can't think how you'd create a design with hundreds of tables by hand - it would surely involve generating tables from some other source. For different types of data I'd lean more for a javascripty-style meta-table with key-values, since I bet all that different type of data wouldn't lend itself well to relations.
What? That is the one thing that stands out as being an obvious "this person has no idea what they are doing" red flag. It doesn't need defended. Having 100 tables is not a problem, in any way. Thinking that having a correct database is bad speaks very poorly for the quality of the developer in question.
Be proactive, take control: cut the project up in parts and focus on those that you can deliver in time. Ever heard of agile?
What is the definition of "fail"? Maybe, given that the project is a hand me down, just barely working is good enough to the client. Maybe there is accepted scope for an over run.
How do you know it will fail? Given my questioning of what a fail is, clearly knowing it will fail is up for grabs.
Will the OP's negativity cause it to fail? This bothers me. An employee who is dooming a project is in danger of dragging the whole thing down.
Perhaps the OP is prejudging things too much?
If the OP "knows" it will fail, the likely hood is that so does every one else.
What seems odd to me is the OP's seemingly isolated position, where it looks like he doesn't get to talk to his co-workers or management. If he knows it will fail, then surely so do his co-workers. Management must also know its not progressing. But, he seems unable to discuss this with any of them, even casually. If this is the case, then my concern would be for the future of the whole company.
Ask for proper priorization and focus on completing as many features as possible, one after the other. It's far easier to build one feature while maintaining multiple others than to build multiple features at the same time, especially with a lot of legacy code.
If they can't prioritize at this point, insist. Point out that in this situation where everyone is stressed for all the possible reasons, with proper priorization you're far, far more efficient than without. For all you know, you can be done with individual parts within hours if you can safely scratch other, less important features that are also in development, only to take them back up and running the next day as they become in turn the highest priority.
If they still can't prioritize at this point, prioritize yourself.
If you don't know it already, find a customer relationship contact and ask for one of the main timesinks for the users that the product is supposed to solve. Let him describe to you the usecase, or let him point it out to you in the functional specs, and do it from start to finish. This one has to work, and that's your new goal in life. Be proud when it's completed, your grunt work is done. Show it to your boss, and let him know that's what requires integration testing right now. Your new goal in life now, is to make sure that this usecase is viable in production. You will find new issues, encounter new problems, but these are better problems because they are not entirely up to your team, they are the kind of problems that a lot more people can understand since they are not purely dev issues. You will get a ton more help at this point, a ton more understanding, a ton more visibility on the project, and management will be able to make a much more informed decision about the so-called deadline.
The key to proper "failing" of a project is to never let it be a complete failure. Finish a usecase and deliver it, so that at least someone could get added value from what the project committed. This is how the customer & management should prioritize for you: make sure that there are usecases where the product is fully functional from start to finish.