Fog Creek Software
Discussion Board

Very painful project, should I leave?

Almost every day for the past couple of months I've thought about leaving my current job.

I'm fortunate in the sense I don't have to pay rent where I live, but I do have to pay a share of utility bills and council tax and so leaving my current job won't be absolute suicide. At the moment the issue is that I won't get another job again any time soon and so I just want to try to save enough money from this job to survive and maybe sign-up for a part-time course.

If I stay I think the director I report to will just get more and more pissed off when things don't get done and so I want to get out now.

Basically for my first project I was handed some code written by two unexperienced programmers who walked out of the job before I joined the company in quick succession of each other. I managed to turn that project around into a working product because I was left alone and got on with all the work.

Now I've been handed another failed, disaster project that was originally started by a director working alone in his spare time way back in 2001! It is a disaster at every level. Unlike the first project it has no sound basis in being a normal application with a user interface and a database. As it is an internal, almost hobbyist project of a director, it has no clear specifications. The code is a mess. It consists of a failed, unfinished parser that could be rewritten using yacc in a day or two. However rewriting isn't an option as it is source code written by a director who is very proud of it. Instead of producing a parse tree, it produces a singly linked list. So all the rest of the code goes around the houses it trying to do something with it. It actually tries to process the stack with one set of code at the same time as the parser is adding to the stack which probably explains why the whole thing corrupts what it is trying to process!!!!

I think the director just expects me as some lowly code monkey to fix the thing by altering a few lines of code.

Software development isn't like this. You need to think about things and write things in such a way as not to mess up. I can't think about what to do because I have virtually been told not to alter his code.

If I was left alone to get some ideas from this project and to start again almost from scratch I will far more likely be able to do it. Certainly why spend weeks messing about with unfinished parser code, when yacc can do the work very quickly.

I haven't been told the whole story. Even though this isn't a released product it does have version numbers. I've purposely been given version 4 code, when version 5 code exists. It looks like he has tried to get this code to work and failed. He is out of ideas how to get this to work and has passed the project to me. However I can't get it to work, because he has told me how proud he is of the work and that he would be upset if I alter it.

Should I resign? This is just painful. This is totally unlike all the other work I've done for the past 7 years.

Tuesday, June 1, 2004

Isn't this the third time you havwe described this exact situation and asked everyone what to do???

Haven't you made up your mind yet? What new information do you hope to receive by repeatedly asking? Let us know so we can help you resolve this difficulty.

Tuesday, June 1, 2004

"However I can't get it to work, because he has told me how proud he is of the work and that he would be upset if I alter it."

The code doesn't work, yet the guy is proud of it and doesn't want you to change it so it does work. What a fucking schmuck.

Sounds like it's time to go, chief. You know what they say, "There are none so blind as those who refuse to see."

The Waterboy
Tuesday, June 1, 2004

Yes, Listener I have posted about this before.

The reason for this is that I have a hard decision to make. OK that isn't quite a reason to post again.

Tuesday, June 1, 2004

Take the "day or two" to write the yacc parser, tell him that you didn't understand his code and it's easier for you to work with your own.

And yes, sometimes software development IS like that. It's nothing to worry about.

As for resigning, the question is whether or not you would enjoy working on the product if it were to be done your way, with yacc parser and all. Then push it through.

Tuesday, June 1, 2004

If you are considering to resign anyway try to communicate first.

Tell your boss(es) what you told us without getting personal. Go in there and explain why the project is failing. Chances are:

a) You will be fired, because his pride is more important than the project success. In which case your resign option was the best one anyway.

b) You'll convince him and he'll give you the freedom to do whatever is needed to get the thing done.

Lack of communication is one of the main reasons for failing projects. We all know it, but often do not act to it. Life is much much easier when you just tell the others what you think. This only works though if you never lie, never play politics, never get personal and admit to your mistakes when you make them.

Jan Derk
Tuesday, June 1, 2004

If you reckon using lex and yacc you can get it running in a day then do it.  Refactor it so it looks much the same but works.  if he cares to go inspect how it works fine, just say that's how you got it to work.

You don't have to go up to him and say look your code sucks and I rewrote everything.

Simon Lucy
Tuesday, June 1, 2004

I'm with Simon.  Fix the damn problem, and then try to help the guy save face afterward.  If you're sure that's a mistake, then yes, you need to quit.

Matt Conrad
Tuesday, June 1, 2004

The easiest way to help this manager save face is not to tell anyone.

If anyone does ask 'what happened to the old parser' you can treat it as such a minor point in the big scheme of the program that it isn't worth even noting.  And if you have to be nice you can say "it was a very very nice parser, but a bit overkill if you know what I mean?" and of course they won't but will think they do.

Infact, I'd go ahead an implement/reimplement as much as needed.  Tempting even to rewrite from scratch, if in your expert opinion that would get results soonest.

i like i
Tuesday, June 1, 2004

Explain to him carefully and tactfully why his code sucks. If he fires you then so be it.

Tuesday, June 1, 2004

If you were thinking of resigning anyway, that is.

Tuesday, June 1, 2004

Dear Mr. Savage:

I would first like to say that I have no sympathy for you.  Having said that, let me assure you that I have been in the same situation.  I had a project with bad code, didn't work for the customers, told the boss we had to rewrite at least a section of it, boss didn't understand because he thinks you only have to change a few lines, I tell boss that we can either rewrite or he will lose the business, boss get's mad, I get madder, I quit, I go home, I rewrite everything just to prove to myself that I could and had made the right decision, I let it go,... two years laters I find out the guy is out of business because he was a bad business man and didn't listen to the expert, me, the software engineer.


These are my exact words.  Mark them.  Use them.  (They are copyright so I do expect a royalty payment.)

P.S. This is a true story.  This film has been edited for length and content.

P.S.S.  You think I'm joking.  I'm not.

Tuesday, June 1, 2004

1. Find out what your boss cares about. (Money, prestige, working product, etc.)

2. Find a way that YOUR success will postively impact what he cares about (make him money, give him prestige).

3. Communicate #2 to him and let him know what YOU need to get HIM what HE wants (#1).

Mr. Analogy
Tuesday, June 1, 2004

Like Mr. Analogy is saying -- this isn't even about the *project*, so it can't possibly be about the code.  Forget about doing the thing right, until you're sure you're at least focused on the right thing...a list of stuff to implement is never about the problem, it's a proposed (and often bad) solution.

Given the reasoning behind the proposed solution, I tend to come up with alternate solution/s, and either change their minds or understand the original proposal.  Either way, it's a win-win thing.  I'm all for ditching employers who consistently fail to get that, but I'd say all of them need to be reminded sometimes.

...I think it's amazing that we as developers get so attached to our ideas of *how*, and so frustrated that we assume all non-developers are power-hungry imbeciles, that we're suggesting (destructively) standing on principle before even asking *why*.  Most situations aren't worth that.  Sometimes it is worth it -- I've left jobs over stuff like this, when it was the majority of my work, when it was chronic and unsalvageable -- but most of the time I just go around the problem and get things done.

Tuesday, June 1, 2004

Savage, work on the Director's product under contract. That means quitting your job, which you seem to want to do anyway.

The company wants the Director's product working, and knows you can do it. I suspect they would be willing to pay more for this than you're currently getting.

If you undertake it on contract, you can impose conditions that make the arrangement fairer. If it's a useful product, retain copyright and have the company pay you a licence fee. That way, it will be worth while for you to spend a lot of effort on it.

You can't continue as you are.

Tuesday, June 1, 2004

Ah... the coding boss, a problem I face every day.
The problem with these acountant turned business owner turned programer types is that they think they can do it all.
They also have huge ego's...a difficult position.

1. Don't ever tell them they are wrong, they will never admit error, even faced with a huge pile of evidense.
2. What they don't know, will not hurt them (re-engineer).
3. If you need to reason with them argue in terms of $$$ not techincal merit. If they had any concept of design they would not write such shite code in the first place.
4. Let them take the credit.

Most people are resonable if approached in the right way, if not quit.

Tuesday, June 1, 2004

I'm sorry but are you the bess? No, of course not. It is not up to you to be coming up with you own ideas, that is the work of your boss who has many more years of experience managing important projects than you. You get a paycheck, you do your job. Doing your job menas doing as you are told without complaining. So, if he says change a few lines and get it to work, than do that. Don't waste his time mith your incompetance because you are not smart enough to make the few lines of changes or know which lines to change. If you can not do it or do not want to, then you can hardly call yourself a professional. If I call a plumber and ask him to fix the pipes in a prompt manner, he can do that. Likewise, if you are asked to fix the few lines of code which your boss has asked you to, then you should either fix those lines or admit you are incompetant and move on.

IT Manager
Tuesday, June 1, 2004

I really hope that IT managers post was meant to have a sarcastic smiley at the end of it somewhere...

Tuesday, June 1, 2004

The problem with that IT Manager is that my boss did not know how to program.  He was an accountant and had never coded before.  I told him what had to be and he couldn't handle it.  I told him the time frame to fix it and he couldn't accept it.

Sure if he would have had a clue, but as it was he was a complete idiot and a jerk on top of it.  Look where he ended up.  He lost the business.  Had he listened to my advice and spent the 30 days estimated to fix the software maybe the customers wouldn't have sued his dumbass out of business.

Tuesday, June 1, 2004


In reply to IT Manager's comment about changing a few lines of code, I'll say what happened today.

The director decided to be helpful today and help out with his new ideas for how the code should proceed.

What happened today, wasn't changing a few lines of code, it was almost refactoring the whole project. The director took the driving seat at my keyboard today and tried to do what was needed with his own code. He swore a lot and called himself various rude names.

In the end the code has been pushed from a non-functioning, buggy, unfinished state into something that can barely even run.

To even get the code to work it looks like we will have to add an extra argument to reams of functions.

I said this morning that we should have a parse tree. My suggestion was ignored.

Today we found out that the code can't work because it doesn't have all the information it needs. If we had a tree structure rather than a singly-linked list, each item could just reference its parent and get the required information.

The code has two main parts. Today we just messed about refactoring the glue, utility type code that fits in between the two main parts of code. It was scary. So much work and the main problems of the code haven't even been addressed.

Tuesday, June 1, 2004

Savage, outsource it to IT Manager for $20 and then get on with your other work.

Tuesday, June 1, 2004

After yesterday's debacle of the director moving the code from buggy and unfinished to even more wrecked, I really do feel like saying I should just do the work from home on one month's unpaid leave and then if the software I write fulfills certain criteria I get paid for that month.

There is still a lot of functionality to write, a reasonably difficult functionality. Having a base of quite frankly silly code will severely compromise this work.

Whether I actually come out and say I should do the work at home is another matter. This guy has history of messing up projects, he does say they have written "internally beautiful" software but somehow the clients never use it. By "internally beautiful" he means he has managed to write a load of functions about 4 lines long but forgotten about the bigger picture of making the thing actually work.

Wednesday, June 2, 2004

Savage, thank you for your comments.

I find myself in a similar situation, working on legacy code that is amazingly complex, adding functionality only to find myself bitten by un-documented assumptions the original developers made.

It's nice to know I'm not alone in the field of being forced to fix something which seems to have needless complication.

As for what to do, I try to reverse engineer some design documentation out of the source I'm given.  From this, I can then evaluate the scale of the mess -- is it only some modules that are hosed, or is the entire calling structure that needs revision.

The tools I use are language dependent -- Understand for C++, and UML Studio work for C, C++, Java, and Fortran.  Visual Studio 6 Visual Modeler works well for VB.

Good luck.

Wednesday, June 2, 2004

Thanks for that last comment.

However the code I've been given isn't production code. It has never been released. It is not finished and what functionality is present had big holes in and bugs.

There are other bits of work the company wants done that could re-use some of the code for the project I'm working on. Unfortunately given the director fondness for his bug-riddled unfinished code I can't see that happening. The code in its current form is simply unusable for other projects. Information is permanently lost for going from something inheriently hierarchial into a flat singly-linked list.

I've worked with huge amounts of legacy code before. That was difficult but I managed it.

The difference is that this code hasn't made it out into the real world and so it a world more hellish than code that basically works, but is badly structured/buggy etc.

Wednesday, June 2, 2004

Life is short. Leave.

Doug Withau
Friday, June 4, 2004


Even if you leave, you go somewhere else where you will find the same thing, again and again.


Wednesday, June 16, 2004


The thing I learn the hard way is that you have to fight.
You are right, he is wrong; you have to tell it, loud, very loud.

If he fires you, what do you care?
He will not. He will if you are going into a compromise and do it his way. It doesn't work, as you said, and he will say that you are not good. Be good, and say it, loud.

It is important that you make the point that you are doing the fix and not him. And that your solution will work and not his. Don't let the incompetents take profit on you.

Fight.  You have to win here, if not in the next job you will have similar problems. Solve the problem today and you will sleep well from now on. Don't leave, but fight. If you leave, you are not honest with you. The programmer in you is a good guy, pay him more respect and try to make him a winner.

I was many times in similar situations. I learn that being nice person is the worst thing to do. You have to show that you know what you are doing and that your solution will work. Even if you need to yell at him.

You haven't been working long in the industry, looks like.
Don't wait 10 years to start fighting. Start now, and keep it up. I mean don't come back, don't compromise with him, after making your point.

This way, everyone will learn that you know what you are doing and people will start listening to you.

Being professional in this situation, means to tell him all the time: "your solutions won't work, mine it will work".
You can spend hours trying to convince him, you are paid to do it.

I would never resign or say "If you don't like it, put someone else to do it". You do it, and do it right.

There are better chances to be fired if you tell nothing, than if you start fighting.

Good Luck!

By the way, if you have a better job, better pay, I don't see any reason to continue here.

Wednesday, June 16, 2004

I agree with Theo: happiness is while you're driving to the destination; at the destination, you are at the end of your way, you're tired and sad and all you would need would be to drive again to new destination.

Anyway, people like you will never win against people like your boss; if our world would work this way, it would be much better nowadays (and after a couple of centuries of freeedom, liberty, democracy, philosophy, art, etc, etc, etc...) Generally speaking, bad people always wins against good people (and I'm talking here about more than 10,000,000 guys, like Joel in his articles :o); even if sometimes the good guy wins, it remains an isolate case, and it would never change the wold but only his mind (and maybe the mind of a couple of other guys in the neighbourhood).

All you can do is to continue fighting, keep this heading and maybe one day, when you will be boss yourself, you will be able to act much better than your boss today (and this is prone to really change the world).

Anyway, even if this thread revealed a lot of interesting opinions (and as you're the "guilty party" for the whole thread, I would say "thank you!"), dont trust anybody: politely listen everybody but finally forget them all and follow your own, unique way.

Good luck,
Gogu X 

Gogu X
Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home