Determining if a software project is doomed.

Question

I'm on a project with slightly over half a million lines of code in various languages. The project consists of distributed applications which talk to each other. There are 2 people maintaining and building this project myself and my boss. The project has high administrative and operational costs just to keep it running day to day while new development is done. However there is no designated operator or admin. I think the project is really undermanned and doomed to fail. My boss who is the other dev on the project works crazy hours (till 1AM on weekdays and weekends). I'm thinking of bailing on this project.

Should I quit?

Posted anonymously for obvious reasons.

EDIT: To provide some more information... This project has been in development for about 8 years.

Answer 1

Check out The Mythical Man-Month: Essays on Software Engineering. The key to salvation lies within. :)

Answer 2

Started to feel trouble?
Yeah, quit and abandon your boss.
He probably relies on you you as on himself!

"Nice" from you...
If I would be you I would ask how to help with this project instead.

Answer 3

Yeah, it's doomed. Even most projects that sound well-architected and well-managed are doomed, and this one doesn't sound well-architected or well-managed.

However, that doesn't mean you should leave. Being the only person who understands the overall project (or one of the few who do) provides good job security. In this economy, that's not to be sneezed at.

Answer 4

A project is only doomed once it is no longer possible to attain its main goals. The project might be finished late and over budget, but that does not necessarily mean it was a failure.

Do you think the goals of the project —whatever they might be— are still under reach?

Answer 5

well, that all depends on you. I really don't know what your software does, but when you find yourself in that situation there are a couple easy questions to ask-

1. Take a minute to think about the long term. Where is your project going? Is there potential for a long term win? How much conviction is in your answer? Was it a maybe?
2. Is the problem we're solving well defined? If it's not, there's a great clue about the future.
3. If the project is sound, and you really believe there's long term potiential, can you find opportunities to work "smarter?" I'll list some examples, but the question is really about opportunity- do you have the ability, time and authority to drive real changes to your product? Examples-
   • Simplify code through consistency and reuse. This may mean elimination of redundant processes, building objects or even minor redesign
   • Streamline workflow in such a way as to improve usability and reduce the need for support. This is usually easier than it sounds- you know what your users do. Make what they do most often EASY before you spend one minute on the rest.
   • Focus on quality error handling. If your code does the work of tracking down errors, you don't have to. Ultimately, your exception handling will show you where to make improvements or automate processes.
4. What's your relationship with your boss? Will they buy into the work smarter approaches? I'm all for working hard and long hours, but not as a remedy for ignoring the things in #3. Spend your time on killer features, not supporting code that is needlessly inefficient.

Anyway, that's where i'd start. I hope that helps.

Answer 6

If you're thinking of bailing, and you're asking questions here, then it's probably best if you bail - you no longer believe you're doing anything worthwhile.

In general, though, you should look at the overall business to determine the "worth" of a project. Is there budget? Does it have executive support? Is there at least a release schedule? What do you score on The Joel Test?

These are some of the things to consider before writing off a job.

Answer 7

Talk to your boss what does he think about the project? Voice your concerns!

If the end is not in sight and things don't improve after the talk, quit. Your health is more important than your job.

Answer 8

So you're going to quit because you're concerned that your boss works too much?

Why not talk to your boss? Ask him if there's any way the company can hire another developer, or modify the application to be easier to maintain. 500,000 LOC is not really that big, and if it's distributed across many apps I don't see any reason to believe it was doomed to fail unless both you and your boss left.

Answer 9

If you have to ask, I'd say your gut is telling you to move on. But make sure you can find another job first.

Some guys know when it will work and when to quit or change strategy and some guys will bring you down like captain ahab and leave you hanging.

Answer 10

1. Is the specification up to date?
2. Are you on schedule?

Any project can turn out however you want it to, but organization is key.

Write a functional specification if you don't already have one. This will help you evaluate where you are and what remains to do. Now build a software schedule (or use tools to manage the process), and evaluate what remains to be done.

If you keep banging your head against a wall, please don't expect a finished product to appear from nowhere. On the other hand, if you take some time out to get everything on the right track, there's nothing that will keep you from a successful product!

If, however, your organisation is resistant to.. well... organisation, then you may be prolonging the inevitable. Make getting a full Joel Test score an imperative and things are guaranteed to improve dramatically. This stuff is famous because it DOES work, reliably, whatever the situation, time and time again.