How should I behave as a developer in a project that's headed for failure?

Question

I am a developer in a 5-member team and I believe our project is headed for disaster. I'll describe why in a moment, but my question is: how should I behave?

The deadline is in 1.5 months, and I feel no matter what we do, this project will fail. I'm of the opinion that we should just terminate the project and stop wasting our time, but politically I think it's impossible for our manager to do that.

What should I do in this case? Should I put in extra effort, or should I just take it easy? And what should I say to the manager?

Reasons this project is headed for failure:

• With 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 - Data model is too driven by a complex relational database (100+ tables)
• Unclear leadership; the manager responds to new information with major changes
• Almost no automated tests or unit test
• Heavily depends on other systems, but no integration tests yet

In fact, we actually just inherited this project (along with the mess) around 1-2 months ago from another dev team under the same manager, who has worked on it for a few months.

Answer 1

Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not 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.

Having done that, keep working on the project in good faith.

Keep in mind, you may not know everything there is to know about the project, its backers, and financial decisions behind it. Management decisions that seem stupid to you might actually be based on smart reasoning that isn't visible to you.

Answer 2

Keep a paper trail (e.g. diary, saved emails, etc). Only include facts and objective observations. Leave all conclusions up to whomever (if anyone) reads what you've written.

As a developer, if you're not viewed as an obstacle to the project you're likely to come out fine from the finger-pointing that will no doubt happen. Your manager may not be so lucky, but that's not relevant here.

Just on general principles, update your resume and make sure you occasionally meet with other devs outside your company. If you're not part of any local developer groups, go join 2 or 3. It takes years to build up a network of friends and acquaintances but in the long run it's worth it. Be sure to look on it as a 2-way street - if you can help fill an opening in your company with someone capable, that's just as good as someone helping you find a job.

Answer 3

I'm going to recommend you take a little time to read 2 books.

Death March is the canonical book that describes a pathological project management style that is widespread in software development. Due to schedule compression, feature bloat, or mismanagement, many projects end up in a bad state; it helps to understand that you are not alone and your project is not the only death march. Author Edward Yourdon categorizes dead-end projects into 4 quadrants, each of which has different coping strategies. Sometimes the only coping strategy is to walk away. I think this book will help you figure out what your range of options is and narrow down what you can and cannot do.

Catastrophe Disentanglement is written more for project managers. It is aimed at figuring out how to triage a broken project: What needs to be cut, what can be cut back, and how to pitch that to customers? "Conventional" software project management gets us into messy projects, and we won't escape our problems using the same thinking that got us into them in the first place. This book is a little harder to read than Death March, but a good one to have on your bookshelf.

Answer 4

3 simple and cynical strategies to maintain career/sanity.

1. See a train wreck in the making - get off the train: Failing projects are terrible for morale and unless you have ninja upward management skills will have some negative impact on your career. Jump now if you can see any soft landing.

2. If that doesn't work keep your head down: People are going to start looking for people to blame - don't make it easy for them! While escalating concerns up the management chain might be the right thing to do it is both ineffective and risky. Your own manager is unlikely to pass your concerns on up and bypassing him/her will not only make you both look bad but could brand you a 'troublemaker' i.e. the kind of person who can be blamed for undermining the project in the first place etc. This of course also means be professional, put in your hours but no heroics.

3. Plan for an emergency exit on T+1: give yourself some options and do the groundwork for a potential internal or external transfer now. Talk to people; there's no reason to wait for others to decide what to do with you when the project funding gets cut or to get swamped in the inevitable 'stampede' of people migrating away in a couple of months.

Apologies if it sounds overly cynical but if you've called it correctly then there is no upside to suffering the unpleasantness coming your way. Be professional, be optimistic but always be realistic.

Answer 5

What impact will this soon-to-be failed project have on your career at the firm, and beyond? In my experience, merely being associated with successful projects is not an indicator of your own personal excellence.

The qualities that you exhibit in the face of adversity and sometimes what looks to be certain failure, often gets noticed by the higher-ups, more so than you think. And I'm talking about beyond your immediate manager.

I personally have experienced seeing my immediate manager get fired for incompetence, and then found myself promoted into his position the very same day. Not pleasant, but it showed that people were watching me, and liked what I did.

Oftentimes, the same chaos and disorganization that comes with a failing project, affords you the opportunity to shine.

So look at the project this way: what opportunity does this failing project afford, for the light to shine on all of my strengths and best qualities? What lessons am I learning from this experience, that will make me a better professional and a better person?

Essentially, the sum of experiences drawn from failures is what fuels true success.

Note: Thomas Owens asked, what specific things a person can do in a project like this. I have a few general suggestions, which I've used as personal guidelines in these situations. Will it help a distress project to miraculously succeed? No - but I've found it has helped me to keep a proper perspective on things, and find personal success in spite of the bad situation.

1) Focus on personal excellence - strive to write ever better code, meet ever higher standards of quality and functionality.

2) Focus on personal metrics - how much code do you write, that spawns subsequent bugs? Reduce that ratio to as low as you can. When asked to provide an estimate for a task assigned to you, are you generally accurate, or do you find that you've over/under buffered the timeline too much? When actually assigned a task, do you provide a good level of feedback on the progression of work, including giving well-and-ahead advance notice of delivery timeline problems?

3) Focus on team metrics - These are just some things off the top of my head: Are other team members lagging because of a dependency on a task you are working on? Are you good at delegating or dividing your task/subtasks to others in the team? Do you find it difficult to communicate with one or more members of the team? All areas that I work on to regularly improve in.

Answer 6

Failing projects can be toxic to the soul, cause depression, over work and low self-esteem.

It's all relative to perspective.

I've worked on horrible projects while sitting across from another guy who had a smile on his face every single day. Oh how I wanted to slap that smile off his face.

Some people aren't bothered by the current state of affairs on a project. They enjoy their contribution, their tasks and are working with in the domain of their interestes. While others, have a strong negative reaction to the current state of things. It's all about our perceived expectations for our daily jobs.

While you might be doing some of the work you enjoy. There is clearly elements in the current project you dislike.

You need to identify what those problem elements are, and address them.

• deadline pressure
• quality control
• professionalism
• guidance by management

There are many teams and companies that don't find the above aspects of development important. What I've found is they often think the following.

• Deadline pressure is perceived as way to motivate people.
• Quality costs more and returns limit.
• Professionalism applies to other areas of the business.
• A manager is a timekeeper and not a person who contributes to development.

These problems aren't yours. It's theirs, and you shouldn't waste any energy over their behavior. If you aren't one of the guys who smiles and enjoys his job even as it heads for a cliff, then you should think about finding a place of like minded developers.

You'll be much happier.

Answer 7

In a situation like this, as the lowest rung of the ladder, there is only so much you can do to help the project.

• Make sure your work is spotless
• help identify the biggest problem areas
• Try to provide answers, not just problems. Look like you are trying to fix them.

Aside from that, you really do have to look after number 1.

• Document everything
• keep all emails, IM conversations
• Try and find a way out of the project if it all possible

Answer 8

Sounds like most projects I've been on. It probably won't end as badly as you think, however:

1. Do your job. Don't worry so much about the overall project as long as you complete your responsibilities.

2. CYA also known as Cover Your Backside. If the project does fail and you suspect the manager will start blaming everyone but himself, make sure you have enough proof that you did everything required of you (see item 1).

3. Make a few polite suggestions for improvement. Don't sound the warning bells, don't be doom and gloom, just be polite and subtle.

For example, if the team isn't writing effective unit tests (or any tests), write a few unit tests closer to what you would like to see and causally mention how doing so helped you solve a particular problem, or saved you time.

Whatever it ends up being if you want to affect change focus on the positive steps that have concrete results. This project may never turn out to be a winner, but maybe the team can learn for the next one.

Also:

4. Opportunistic refactoring is your friend.

Answer 9

Try to be proactive about finding a new way to achieve success for the project. Think about how you can propose some alternatives. Right now your boss is probably getting beat up about the project being a failure, wouldn't (s)he appreciate someone coming in with solutions instead of problems?

Maybe there is a way to split the features into staggered deliverables? There are often degrees of "must have", so see if you can get those prioritized and group them into milestones. Better to have some product at the end of the timeline than nothing. Or consider splitting the team between people working on new functionality and others working on the stability, this way you can show some progress on both fronts.

If these efforts succeed, you will have shown that you are a team member who can find a way to succeed, if not, you will still have demonstrated that you don't give up and will work to find a solution.

Answer 10

1. Work hard; but not at the expense of your family or your health.
2. Keep a record of all critical design decisions; especially as they pertain to your work.
3. Keep networking, and keep your options open if the situation becomes too difficult or you become a victim of a mass layoff.
4. Try not to think of your project as a "failed project". Everyone likes people who stay positive and fight hard in the face of adversity. So for as long as possible, try to be that person. A positive outlook, grit, and determination are always good for the workplace.
5. If you're anticipating a failed project, then you're anticipating a post-mortem meeting. At the post-mortem meeting, everyone will be held to account. Be prepared to defend all of your code. [Note: As a general rule, you should always write clean code so that it's easy to defend it later.] If you have email or design document that inspired your decisions, then that's even better.
6. At that post-mortem meeting, try to stay positive; and only present your email and design document evidence if your judgement, effort, or workmanship is called into question.

Answer 11

What I've found most effective is Robert L. Read's recommendation on how to fight schedule pressure. Here's what Read writes:

The key to fighting schedule pressure is simply to turn it into time-to-market pressure. The way to do this to give visibility into the relationship between the available labor and the product. Producing an honest, detailed, and most of all, understandable estimate of all the labor involved is the best way to do this. It has the added advantage of allowing good management decisions to be made about possible functionality tradeoffs.

The key insight that the estimate must make plain is that labor is an almost incompressible fluid. You can't pack more into a span of time anymore than you can pack more water into a container over and above that container's volume. In a sense, a programmer should never say ‘no’, but rather to say ‘What will you give up to get that thing you want?’ The effect of producing clear estimates will be to increase the respect for programmers. This is how other professionals behave. Programmers' hard work will be visible. Setting an unrealistic schedule will also be painfully obvious to everyone. Programmers cannot be hoodwinked. It is disrespectful and demoralizing to ask them to do something unrealistic.

When you say that the project is "headed for failure," that's based on your assessment of what tasks need to be done and how much effort each one of them will require. Make that assessment explicit, understandable, and detailed. Separate tasks into their component parts; explain in as much detail as you can how development time will be spent.

Once you do that, you have a solid foundation for discussing concerns with management. In all probability, once you've broken down your assessment into all the specific tasks that need to be completed, you will be able to demonstrate that the job takes more time than you have - possibly much, much more.

Once you're discussing this detailed schedule with your manager, be prepared to be flexible. Your manager might say "Task X won't take a month; it'll take a week at most," or "Task Y is entirely unnecessary, cut that from the schedule." You can certainly discuss these points, but what's far more important is to reach an understanding between you and your manager on some realistic version of a schedule. That way, if you're not being allocated time for, say, testing, then you've got an explicit directive not to test, rather than just running out of time "unexpectedly". And it's definitely possible that your manager is legitimately willing to explicitly cut certain corners in order to ship on time - there's plenty of cases where that's a perfectly reasonable call!

The estimate gives you concrete substance to debate and discuss. It puts you on the same page; it helps you feel confident that your manager has taken your concerns into account. And it brings you to the point where if your manager is plainly asking the impossible, it will be perfectly evident to both of you. If the project is well and truly doomed, you will have made that clear, and it will be up to your manager to decide precisely how he wants you to spend your time.

Answer 12

There are reams of practical (and otherwise) advice here already, but to me the keys to this mystery are the following two items (emphasis mine):

The deadline is in 1.5 months

and

...we actually just inherited this project (along with the mess) around 1-2 months ago from another dev team under the same manager...

So....

Welcome to Team Patsy The Avengers

The prior team had better things to do...than fail. And somehow the manager went along with that. Changing teams this close to deadline is not the best project-management move to make, so...what's up with that?

Correction: The prior team was replaced, ~3 months before the deadline.

--> Find out how the prior dev team managed to escape, and do that. <--

3 months is barely enough time to come up to speed on a system of this apparent size, much less correct its architecture, add tests, and finish it. You need more time

And if you can't do that, unless you are absolutely certain that the project will be extended indefinitely, or aided by magic elves or something, you do not want to be the last man standing left holding the bag.

Harsh? Yes. But while poor planning (at least!) by prior teams/managers is not your fault, 'failure to deliver' will be.

The prior team bailed. The prior team was kicked to the curb. What does that tell you? It tells me that you are the turnaround team...and your manager is counting on your heroics to save the day.

A 5-person team, and 1.5 months to go. The new team has only had the project for 1-2 months, so the new team is not even over the learning curve. Taking a rough guess at the size of this project, it looks to me like there is no way the new team would have been over the learning curve even if the project had no problems at all.

So, I (still) think you've been shafted.

If that is the case - and only you can decide what is true, or what you want to believe - you do not owe anyone an explanation or an apology for getting out of the way of this train wreck. You do need to be discreet about it though.

I doubt seriously that the manager is unaware that the project is in jeopardy, which means that gentle explanations will get you nothing but negative attention. Unless your manager is Mr. Rogers, your future is in jeopardy.

But always remember: do not take career advice from strangers on the Internet.

Answer 13

Since your manager knows it will probably fail, you're better off than most. I would consider working with the manager and see if there are any parts/features of the app that can be excluded.

Too often we think every client request is a 'deal killer' and go out of our way to promise the delivery. Until someone works with the client and probes deeper, you may not be able to make these decisions. If you're not able to do this, still try to deliver what you think is most important. Sometimes it's easier to ask for forgiveness than permission.

Answer 14

I participated in three projects that were clear failure. These were quite painful but looking back, two of three did not have negative consequences on my career, and even third one wasn't the end of the world.

Here are some observations I recall.

Developers at junior positions ("code per spec", "fix the bug", stuff like that) don't get affected much, unless they slack off due to lowered morale in the team. At positions like these, a sensible and even sometimes successful survival strategy could be just doing the best you could.

• ^{For example, one of the failures I experienced has been overcome by plain, methodical fixing of more than hundred known bugs which (coupled with particularly smart approach of promoting this progress by tech lead) eventually led upper management to decision to recover the project and give it yet another chance with a new release, which in turn made a reasonable success.}

---

Programmers at more senior, influential positions would better be prepared to share the negative consequences of project failure. An architect, tech lead, senior developer are typically expected to make an impact big enough to be considered responsible for project success or failure.

At senior position, one would better be prepared to gain from failure "indirectly", by analyzing what went wrong and what could have been done better.

These bits of knowledge, post-mortem lessons may be invaluable if learned right, the very successful career at senior positions may depend on how well these are learned, as explained in this brilliant answer at WP:

Judgement comes not from success, but from failures. Most companies want to hire people that have had their failures paid for by previous companies...

---

On a more practical note, one can consider "next / update release" approach as a possible way out of the failure. Coincidentally or not (I think not), but both of the failures that didn't damage my career went by very similar scenarios: release N was a total disaster, release N+1 was tolerable, releases N+2 and later were plain success.

Walking in your shoes, I would most likely put some effort in preparing / promoting the idea of "next release". Make (and communicate!) something like a tentative list of known issues that you would want to fix after planned release. Draft an informal, rough road map for next release(s).

Think of how you could communicate these ideas to people around you, how you could influence management to consider this plan. If the project has someone with good marketing skills, try to involve them into amortizing the failure damage by wrapping up coming release into smoother terms, like "early access", "beta", "customer preview", "introductory release", stuff like that.

Think of a backup plan in case if higher ups will appear deaf to this idea. Remember above story about "fixing of more than hundred known bugs"? there is a chance for things to change, really.

Management may appear deaf to next-release ideas now, but there is a good chance for them to reconsider in the face of strong convincing evidence of project quality progress.

• ^{It is quite likely that there will be rather long time between freezing code for planned release and management decision to drop it completely. That time is your chance: if you focus effort on fixing known issues and properly "evangelizing" the progress, this could make a difference (as it once made to me).}

Answer 15

This is an incredible opportunity for you! Let's take an entrepreneurial viewpoint on this.

Assuming that management wants this project to succeed you are in a great position to help them do so. The reason this realization is so important is because you have to develop the conviction and confidence that the warning signs you're seeing are in fact going to lead to this project's failure[1].

This is your chance to practice important skills in systematic thinking and interpersonal communication. Understand and visualize the issues and potential opportunities that are being missed so you can develop a strategy to communicate these as clearly and simply as possible.

Recognize your opportunity here to improve you skills.

[1] Canceling the project would actually be success. Failure would be spending good money after bad.

Answer 16

What can you do

• Treat this in your own self excellence terms, it's "their" project, but also yours, take ownership even though you know it will fail. Why? because a) you might help it fail a little less, b) in time of challange, this is where you learn the most c) you should measure yourself via your own metrics of excellence, doing your best might not save the project, but you might end up still proud of yourself

• Talk to other fellow developers and see what they think, you will probably find out that many share the same frustration, if done carefully (don't make people think you want to start a mutiny or something) then this can help not just you but others as well

• Ignoring the problem is not going to make it go away, talking about ways how to, against all odds still pull it through, e.g. at least get some decent must haves, or the main "wow factor" use case done right, might make this project fail less miserably. How to do it? well, few ideas of "when going gets tough tough gets going" or "desperate times justify desperate measures" and other cliches, for example: massive use of OSS, extreme programming / agile methodologies, weekend hackathons (volunteers only, not forcing people to work weekends). This is time where you can show leadership (carefully if you are not in a team lead / senior position) but you can take this advantage and become their mockingjay, just get people to feel that they might get this project just a little less fail than everyone knows it will. You can show some leadership skills here that might help you later along the way, treat the problem as a challenge.

• Make sure your management knows, but very, very carefully, if they know, they'll appreciate you telling them this in a non confrontational, calm way, if they don't they will appreciate it even more, and wonder why no one told them about it before. You should tell them this as a service, without any emotional side, just plain facts, and without an agenda. If they'll ask you what you think they should do (which is a great sign, but rare) then see the next section

What you can't do, but your management probably should

• They should not add more people to the project "to help" see this

• Call the customer immediately and tell them the bad news. Why is this a good idea? well, I'll leave quoting the manifesto for agile software development, but even without it, even water fall lovers hate bad surprises. If the customer knows in advance this project is doomed to fail, they will be unhappy, but will be much happier that you tell them there are issues before it blows in their face, and that you are on it, and doing your best to accommodate it. The customer can do many things but most of them are not worse than finding out in the last minute they don't have a deliverable (or they do but it's of non usable quality). The customer will appreciate it as they will be able to delay hiring testing staff, offshore IT people, change their internal training plans, and all just because you were honest with them.

• with the customer, think of ways to still make something out of the project, the most common one is descoping things. for example there might be some features that are just too hard to develop the way they were designed, and if the customer will agree for some small modifications and simplifications, then some features will become simpler.

• Update their own higher management, it will help them keep their job as well...

What you should NOT do

• Ask to add more people to the project (see this)

• Quit / look for another job (at least not yet), this is something you can learn from, and what will make you one day a better developer or better manager. You'll learn to appreciate many things better, better time manage, design better, write code better, and work with peers and management better. Look for a job after these 2 months are over if you don't like working there, not because of any other reason.

• Whine, complain, or be negative about the project, management, the bad design you inherited, the newbie developers you got to mentor that it takes you 3 hours to explain them to do something that takes you 1 hour, be positive as much as you can.

• Criticize management and become a target as a trouble maker, they are in the same boat, and they might know things that you don't, all you can do is update them (always update your own direct manager, never bypass her / him)

• Blame people, (or yourself), it doesn't help, never

• Take it too seriously, unless it's medical equipment, no one is likely to die if you miss the deadlines, it's software, we miss deadlines for a living, relax.

That's just my two cents, YMMV

Answer 17

Find the problems your project is running into and try to clearly quantify as objectively possible. With every "metric" you quantify make sure you define why you believe this metric is important. You want to give your manager insight into what the consequences would be if a certain metric would not be within "acceptable range". You will need to give some guidelines for each metric to indicate which values are "Good", "Acceptable", "Problematic" or "Bad". Define every criterion up front. If possible you could describe what would be minimally needed for a project to success and contrast this with the current project.

• Static Code Quality can be quantified by lots of static analysis tools. You can keep this as simple or detailed as you see fit. The metrics I suggest you start with:
  • Cyclomatic Complexity
  • Size of your code (eg, Nr of lines per function/class, number of files, number of tables...)
  • Identify which modules are too large
  • Duplication.
  • Adherance to code style
• Defect rate
  • per KLOC by module and or subsystem (identify troublesome parts of your system)
  • you could calculate how much per team member but I think you should keep that for yourself
  • solved vs found
  • time needed to solve a bug (perhaps if this is inclining make a graph of this)
  • perhaps make an estimate of how much time is needed if this keeps going at the current rate
• Planning
  • Extrapolate time used for the features built. Take into account complexity of the feature. This doesn't have to be very precise. What you want to convey with this would be along the lines of "Feature A, B and C are around the same complexity of D, E and F. With features ABC used 170% if the planned time. If nothing changes we expect the same time is needed for DEF" or along the line of "The average feature is taking X% time longer than calculated. We have no reason to assume that the rest of the functionality is easier to build so we should compensate for this in the future planning. It is of no use to have a planning if it is not realistic.
  • Try to have some monthly or preferably even shorter release schedule. If only internal. This could help you further with extrapolating the time you need for the project. This could also save you from making unrealistic commitments (if you don't commit to new work before a release is done). Make a planning for each cylce and sure new features only enter into the next cycle (ie. they can never be added to the current cycle).
• Test coverage: explain the "normal" test coverage values and show how what your current coverage is
• Documentation: How much % is actually documented? How good?
• Modularity:
  • Class based (coupling and cohesion)
  • Package based
  • Subsystem based (how many communication paths are there?)

Answer 18

You should go to work and do what you would do on any project, whether it was succeeding or not. You are being paid to perform your job. Do it to the best of your ability. Assuming you aren't the project manager/lead, it is not your responsibility to decide that a program should be cancelled or not. You deciding to slack is the same as you making the decision to cancel the project. That's not part of your job description.

However, in the bigger picture, that doesn't mean that you should be working 50, 60 or more hours per week to try and meet the schedule. Once again, that's management's job to figure out how to achieve the project objectives. 50+ hour work weeks is not a reasonable option unless they are willing to pay overtime and you are willing to put your family life on hold. Once again, it was management's job to put together an achievable schedule. They can't assume that they can force employees to ignore their family life in order to meet unrealistic schedules.

Also, while the schedule may say 1 1/2 months remaining. That is probably not the "drop dead" date. Some customers may take what you have by that date, even if it isn't all. Some customers may come up with extra funding, since they've already sunk a lot of money into the project. Sometimes the company itself may take on the extra costs to ensure a satisfied customer. All of that is out of your control. Do your job to the best of your ability. That will give management options to work with that could turn a disaster project into a great success story. I've seen it happen many times.

Answer 19

I can only reiterate what others have said, but I emphatically emphasize: Always strive for your best work and keep a paper trail. for both CYA and technical reasons.

Any fall out coming your way depends on managements' personal character; but let me tell you it's hell being on the receiving end of incompetent, lying management. But the very worst you'll leave with your self (and peer) respect intact.

Keep good notes of technical aspects of your Death March. When you get the inevitable interview question have you been on a failed project; why did it fail and what did you do to try to prevent it? Bonehead management is not an answer - even if it is the reason.

Answer 20

It may be an easy way out to assume that it is an inevitable and utter failure and just give up on the project. As a consultant I am often invited to help with the projects that are in various stages of degeneration, failed or failing and part of what I am being paid for is reviving and completing such projects.

What you view as a complete failure, may not be perceived as such by everyone, depending on the perspective. In an ideal world, every feature would complete, coded elegantly and independently of other systems and every line of code tested. I haven't seen a single, project that looked like that in rev 1. In real world, shipping a project means taking some compromises, maybe even missing some key features but the product can ship and even though it will be beta quality at best, at least you'll get the feedback on which things to fix first. The upside of this is that it may inform the management that software is never done and rather than trying to develop a certain v 1.0 in vacuum it is better to iterate and respond to changes in an agile way. Finally for you as a developer in this position, I think the key thing is to develop as good code as possible in these conditions - document it, write tests yourself, if you have to (especially for external dependencies) and use your knowledge of the system to communicate which features are truly crucial and must-have and which ones can wait a week or a month. Make yourself vocal about your concerns and justify them as you did to us. Rather than prepping for plan B, prepare for the fact that you and other poor souls will probably be fixing all that buggy and not done code yet AFTER the product has shipped - as stated above this means writing your code in a modular decoupled fashion - if you think that the persistence layer code is bad, hopefully you should be able to replace it completely in the next revision. Finally, don't despair - dealing with such situation is part of what you're being paid for and it's a learning process. Regardless of the outcome in this particular project, this will count as a valuable experience in the future.