How to deal with my failing project?

Question

I just graduated with an M.S. in computer science. I did not have a background in CS before I started the program. Unfortunately, halfway through my degree, I decided I did not want to be a developer and skimped on all software-engineering and development courses in order to take more math classes that would help me out with my new career goals.

Good news: I got a job in the new field I wanted my career in.

Bad news: After 3 happy months, they decided to stick me on this huge software development project with one other developer. Neither of us have any experience developing and distributing software on a large-scale.

We have "succeeded" in getting a prototype working, but in reality, we are the only two people who actually know how to run the program. The amount of "special" knowledge required to get the program to run as expected is enormous. Every time we are asked to test a new scenario (this is a microsimulation model), we have to make major programming changes because the model was not designed to handle that scenario. When we finally get that scenario working, the requirements change again.

I really really want this project to succeed, but I am getting really really nervous, as both of my bosses (who also don't really have experience leading software projects or managing software development on this scale) expect this program to be distributed for company wide use very soon.

Problem is, I've made a few suggestions for how to improve the development process (slow things down and test), but they never seem to go anywhere. The response is always that we are on tight deadline and we just need to keep going going going. My nightmare is the day when we decide the model is working and that we need to distribute it. Things are going to go wrong when users input a set of assumptions that model can't handle or use a starting dataset with characteristices different than we expect. Then, I think, it will be my ass on the line.

I'm doing the best I can and working about 65-80 hours a week, but I don't think I'm going to be able to pull this off.

Any advice? I'm scared to make suggestions or suggest that the project is failing under the current conditions, but I'm also scared about what will happen if I don't speak up.

Thanks.

EDIT - I also wanted to add that another reason I am afraid to speak up is that I know what we should be doing (testing, design, etc.), but I don't have lots of experience with that either. I have general ideas for how we need to go about changing our ways, but I don't think I'm experienced enough myself to implement them.

Answer 1

That's really unfortunate. I'm sorry to hear that.

Basically this is a management problem. No significant project should be effectively dumped on neophyte programmers. The fact is that even though you might know how to code the business of software is so much more than that, which I think you recognize (which is a good thing).

Any significant project should have at least one person on it that is experienced in and knows how to deliver software. The mentoring aspect for less experienced programmers is invaluable as well.

I would be raising your concerns with your manage, preferably in writing. I say this because you also don't want to get blamed for it going wrong. If the response you get is insufficient then you have a difficult choice. Going above someone's head can be a risky move as you could potentially embarrass and that's something you want to avoid doing if you can.

Are there more experienced developers around you could talk to? Or even get on the project part-time? Someone else might be able to give you some options that won't be shooting yourself in the foot (politically speaking). Options that spring to mind:

• Getting a more senior person on at least part-time;
• As a new programmer, ask for a mentor in the organization. You can even skip your manager and do this through HR. That's not an unreasonable request;
• Find out who the relevant stakeholders are. I'm talking about those people really driving the project and want it to succeed. Talk to them, informally if necessary, about your concerns highlighting the fact that you want the project to succeed and you'd just feel more comfortable with some experience leading; and
• Familiarize yourself with best practices as quickly as you can. I'm talking about learning about things like unit testing, etc. Pick up and read something like Code Complete, The Pragmatic Programmer and the Mythical Man-Month.

Just try to approach the problem positively so you gain cooperation rather than put people on the defensive.

Answer 2

You need to speak up now! Tell your boss the solution is not a 'general' enough one to ship (explaining why), and that you need more time (and possibly more resources) to make it happen.

As irritable as he gets, he is responsible for the project, and if failure is not an option he will have to intervene in a helpful way, throwing you out of the company is highly unlikely.

You'll more likely be in a sticky situation if you do not speak up now.

Welcome to the world of software development!

Answer 3

Speak up, say you need more programmers, more time, whatever you need.

You run the risk of being replaced or fired no matter what you do, but at least if you speak up theres a chance you'll get the help you need and maybe finish the project successfully.

No chance in hell of that happening if you keep quiet and let them think everything is going okay.

Side note: This reminds me of the story on TheDailyWtf.com where a lady was hired to do a project that everyone thought was going great, and then a short time before it was due, she had only produced a single line of code that said something like "I'm awesome". The managers biggest problem was that she didn't ask for help at the start, and instead waited until it was too late for anyone to do anything. (Anyone remember the link?)

Answer 4

I agree with those who say "talk to your managers". As an organization, you need to figure out what would right the software. From your bosses' perspective, the project is going great ... every time they give you new specifications you deliver.

The only real problem I see is that you are working 65-80 hours per week. Unless you're getting paid OT, those hours probably aren't worth it.

Answer 5

Two developers with little experience + no QA support + project manager who doesn't understand SDLC + constantly shifting/amending requirements = disaster, but you already figured that out :-)

I would recommend reading "Death March" by Edward Yourdon (http://www.amazon.com/Death-March-Developers-Surviving-Impossible/dp/0130146595/ref=sr_1_1?ie=UTF8&s=books&qid=1249691708&sr=8-1) for some insight. It's a book about how to deal with problems more or less exactly like yours.

Regarding your edit: Software developers should NOT be testers. Aside from being a completely different skill set, testing your own code is like proofreading a document you have written. You are simply too close to the source to be able to see any errors effectively.

Regarding the need to keep going going going and not stopping to see if there is a better way: I will leave you with one of my favorite vignettes (stolen shamelessly from condinghorror.com)...

There's a guy who stumbled into a lumberjack in the mountains. The man stops to observe the lumberjack, watching him feverishly sawing at this very large tree. He noticed that the lumberjack was working up a sweat, sawing and sawing, yet going nowhere. The bystander noticed that the saw the lumberjack was using was about as sharp as a butter knife. So, he says to the lumberjack, "Excuse me Mr. Lumberjack, but I couldn't help noticing how hard you are working on that tree, but going nowhere." The lumberjack replies with sweat dripping off of his brow, "Yes... I know. This tree seems to be giving me some trouble." The bystander replies and says, "But Mr. Lumberjack, your saw is so dull that it couldn't possibly cut through anything." "I know", says the lumberjack, "but I am too busy sawing to take time to sharpen my saw."

Answer 6

Okay, I really think my experience can really help you on this one! Right out of high school I landed a software development job as a Jr. .NET Developer working directly under a friend of mine (the Sr. Dev) who got me the job.

The first day I got an introduction to the tools and resources used to develop using their stuff. Then, I did a crash course over-night on CAB (never heard of it for the life of me prior), and I got about 2-4 hours of sleep. Woke up the next day, started work.

I had huge responsibility for myself, and to this project. This was financial software going into a rebuild of their product (I worked on a couple modules). Not only did I have to estimate my work (which I slowly learned from my friend, who estimated the first projects for me), but..

I had to show off my work at SCRUM's, explain how the features worked and how I did it, etcetera.

throughout this, there were tons of moments, I ran into bugs I've never dealt with before, using a framework I've never heard or used of, and under tight time constraints.

---

THE WORST THING YOU CAN DO IS NOT SPEAK UP. I CANNOT STRESS THIS ENOUGH.

---

I blatantly told my bosse(s):

1. I've never touched Sql stuff before, I will have to learn this so I will struggle and take longer
2. I've never touched CAB stuff before, I will have to learn this so I will struggle and take longer
3. I can only tell you if I can do it once I start doing it and find out how difficult it is for my skill set

Everyone appreciated my honesty, and how open and modest I was about my skills. But, with a lot of stressful days and 16 hour workdays, guess what?

I PULLED THROUGH!

I was 18, right out of high school, and it was the most grueling, hard 6 weeks of projects I've done in my life. I loved it!

I learned a ton, and I was constantly nervous, stressed, and overworked. I kept telling the CEO "I'll keep you up to date, if I can't do something I will tell you"

The worst thing you can do is not speak up and have the company lose money when they can get you some help, either from a outside developer, or other.

Communicate... It's important. Be honest... It's important. Be modest... It helps..

Work hard, do what you can. As long as you do that, what else can you do? You can't get dinged for not trying or working, because you are.. what more can they expect?

-- think about it I had never used source control before.. I had never estimated my work before, yet alone heard that people do that sort of thing I had never touched any framework, CAB, Unity, or other I had never developed under time constraints .. so on so forth

Seriously, I hope this helps, because it looks like your situation is simlar to what I had. Don't let it get to you so much. You're human. Remember that. Just work hard and true, and don't give up!

Answer 7

• I agree with those who say that this is a failure of management. They are exploiting you, as well as producing poor quality software.

• Stop working 80 hours a week. 60 may be sustainable, and pretty much expected for software development. But I find the hours past 60 per week are wasted, because I'm too tired to do good technical work. I may even need to discard some work and do it over.

• Document your recommendations for improving the development process. Don't frame it as slowing down progress. Focus on the quantifiable benefits, for instance how fast it will be to detect and correct bugs once there's a suite of automated tests.

• Go ahead and start developing tests, don't wait for permission because it will never come. Do it gradually so you can still meet deadlines. Within a few months, you'll have some testing infrastructure.

• Document the "tribal knowledge" that you and your coworker have. Don't wait for permission to do this.

• I was going to suggest reading "Death March" but @pjabbot already recommended it. "The Mythical Man Month" by Fred Brooks is another relevant book.

• Start looking for a different job in your preferred career. This job is going to implode if you can't convince the manager to use more professional software development processes. Any business that depends on using underqualified workers or overworking them is not sustainable.

Answer 8

You are still a young padawan. Not that I'm old... but in terms of doomed projects I have some experience (like everybody here, working on doomed projects is part of life, and seldom depends on you).

Personally (NB: personally) I would speak openly about the status of the project, and if the managers don't accommodate your opinion, then I would quit. I did it already, or refused project by the basis of being unattainable. It takes some guts, and some independence, to be able to walk away from your salary, potentially from your current city, because you know that the conditions are not sane for the success criteria.

My suggestion for you, however, is to stay.

You should stay because a doomed or failed project teaches you a lot anyway:

• to recognize when a project is doomed, and what happens before and after the time has come for the proverbial manure to hit the fan.
• to improve as a future manager, by seeing the mistakes of other managers.
• to see the big picture. If a plane flies straight, everybody can keep it going. but to become a great pilot, you have to put yourself on a crash route. Then, you learn how things work and interact.

Answer 9

After reading your post, here is what i got out of it:

1. You graduaded with a MS Computer Science but your main interest in more in the the science parts of things rather than writing code. [Nothing wrong with that BTW :) ]

2. You landed a job in the field of your chosen career and "magically" 3 months later (which at least in the United states is considered some sort of probationary period) they dragged you by the hair in front of a machine , shoved a keyboard under your nose, cracked the whip and said "write me some code dammit".

3. It's obvious you no longer have a job in the field you wanted your career in, instead you are doing a job that you didn't want to do in the first place.

You really want this project to succeed, because you are only looking at what's in front of you every day. "They" know that. Either by your own integrity/peronal pride etc or the not so accidentally cultivated atmosphere where you work, you feel attached to this project.

Like soldiers stuck in foxhole, that the generals know they won't leave their buddies behind so they'll fight until they are all dead.

Like the others recommended, do make the situation known, document the shortcomings of the current way of doing things etc etc. CC your boss, you boss's boss and even his boss. Right after your get your resume together!!! Read 1,2 and 3 and decide if that where you really want to be. There will be many projects that you will want to be involved in without being conned into it.

Had you said you had a Masters in Philosophy and what you really wanted to do is write code, I would not even have posted a reply because everyone else before me, has given you great advice if this is indeed what you want to pursue (although 1,2 and 3 contradict that).

Answer 10

CYA: a) Document the original 'goal posts'; and the new 'goal posts', with man-hour figures on the impact of 'moving-goal-posts.'

b) Create your own test cases; these are ALL INPUT SCENARIOS: typo-errors,etc. and have someone else put your software through those tests to see/document what the return is.

c) Release two copies to two potential users to play with. These users should not be either high or low on the expertise range, but should be able to document (write in plain english) what they did, what they expected, why it was confusing, etc. candidly without their immediate supervisors being in the least bit involved.

d) Insure that each display 'page' of your software includes the words "Beta- not for general release"; on the off-chance your software will be released without your blessing.

e ) As said previously, document the need for a,b,c to be completed before Beta gets dropped.

f) get your resume out there; don't use your real name. Welcome to the real world.