Horrors of War

So I'm working on this project. Its not huge, about 4000 lines of code, but It started out as one thing, and has been and gone through several different states of being since then (feature creep with overtones of we had to figure out how to do the thing it does in the first place). There is a lot of code that is no longer executed, some that executes but whose output we really dont use anymore, and its basically one F-Huge blob of sphagetti code. Well, I suggest a rewrite and a new approach today that will eliminate this happening in the future, and wouldn't you know it, the boss was ........ed because I guess he was expecting the project to be finished this week or something based solely on the fact that the customer is coming to see the project because he promised them it would be finished despite the fact that I urged him NOT to have them come up until we had it finished and tested.

Yeah, that sounds familiar, sort of.

Hope you can resolve something - perhaps you can explain to the boss that the prototype you have now is not a commercial quality product, and your boss can "Manage the customer expectations".

--
Mats

Yeah, the problem is the customer AND the boss have no clue about software development. An application like this generally involves about 100 man years, and they are getting testy because 2 guys (the boss and myself) have spent 8 months on it. The bosses previous experience has been a few Labview applications and some simple C/C++ class based algorithms.

Originally Posted by abachler

An application like this generally involves about 100 man years.

100 man years for 4000 lines of code? O_O

That's a pretty complex project.

So, show it as a prototype and explain that if they took it now, they get code that is not done cooking. Doesn't sound like it's your problem - it's the Boss's problem.

Originally Posted by SlyMaelstrom

100 man years for 4000 lines of code? O_O

That's a pretty complex project.

The assumption being that it owudl be more than 4000 lines when finished. So far we have 16 man months. But truthfully, not all of that time has been spent on just this application, so the real figure is probably half that.

So your boss assumes you're finished... and you estimate that you're approximately less than 1% complete? Are you planning on consisitently scrapping the whole project and starting new every few months? I think I'd leave that one out of next year's PMO.

I don't want to leave any assumption that I've had any experience working on large scale projects. In fact, at the prime age of 21, my professional experience has yet to move outside of Visual Basic, SQL, and a little Perl. (¬_&#172 I'm sure there is a lot of planning that needs to take place (and hasn't) and plenty of revisions that need to be done (and haven't)... but surely the project time estimations of the two developers should not be that different. At the rate you appear to be moving, unless your manager decides to put two dozen or so more software developers on the budget (not to mention a massive amount of overtime)... your software will likely be well past obsolete by the time you finish. (if you finish)

"May you live in interesting times."

Chinese wisdom never ceases to amaze me. But alas, such is the life of a programmer...

After years of slavery, I finally broke free. Can you?
There should be 24h helplines for programmers, I say!

Originally Posted by SlyMaelstrom

So your boss assumes you're finished... and you estimate that you're approximately less than 1% complete? Are you planning on consisitently scrapping the whole project and starting new every few months? I think I'd leave that one out of next year's PMO.

I don't want to leave any assumption that I've had any experience working on large scale projects. In fact, at the prime age of 21, my professional experience has yet to move outside of Visual Basic, SQL, and a little Perl. (¬_¬) I'm sure there is a lot of planning that needs to take place (and hasn't) and plenty of revisions that need to be done (and haven't)... but surely the project time estimations of the two developers should not be that different. At the rate you appear to be moving, unless your manager decides to put two dozen or so more software developers on the budget (not to mention a massive amount of overtime)... your software will likely be well past obsolete by the time you finish. (if you finish)

I woudlnt say 1%, and I'm nto scrapign he project. What I proposed was a rewrite to put the project into a more manageable modular configuration. I think we are basically over half done, but far from finished.

Originally Posted by abachler

I woudlnt say 1%, and I'm nto scrapign he project. What I proposed was a rewrite to put the project into a more manageable modular configuration. I think we are basically over half done, but far from finished.

Well, I guess the lesson learned here is to be modular from the beginning. Programming is hard and I'm sure I'd find myself in the same situation that you have. At least, try to salvage what good you can get out of what's been done and put it into a more modular frame. Don't try to sell it to your boss as a re-write... sell it as "improvements in stability" or something sugar-coated to that extent. He's gonna try to blame you for this when the customer isn't satisfied, so you don't want to ........ him off more than you have to.

Regardless... consider that your client has no knowledge of software and does not know what your application is fully capable of, you can probably sell it as doing more than it actually is if you know how to phrase things correctly and make it shoot some pretty lights here or there... I'm sure it won't be as bad as you may be thinking.

If the code works then don't worry right now about it's super uber elite C++ 'ness. Just get it working and the boss will be happy even if you are cringing all along the way. Later on in future projects you can modularize it and make it 'prettier' even if it adds next to nothing to the actual program.

I'd say it's a bit late in the dev phase to think about re-writing it. You essentially are saying you started with a poor design, built upon it, and now you want to fix the design? That entails much more effort at this stage of the game that may or may not be worth the fuss.

Does the app meet the project scope (ie does the code do what the requirements docs specify to has to do and without crashing?)

If so ship it.

Learn from the mistakes (*) and pay more attention/time to design next project.

I endevour to ensure each app I write is better than the last one. I do this by learning something from each app (even if that is not to ever take that approach again..).

If I went back and applied this new knowledge to every app I have ever written, would never get to write another app.....

[* It is only a mistake if you make the same error again, the first time is a learning curve.]

Originally Posted by Bubba

If the code works then don't worry right now about it's super uber elite C++ 'ness. Just get it working and the boss will be happy even if you are cringing all along the way. Later on in future projects you can modularize it and make it 'prettier' even if it adds next to nothing to the actual program.

I'd say it's a bit late in the dev phase to think about re-writing it. You essentially are saying you started with a poor design, built upon it, and now you want to fix the design? That entails much more effort at this stage of the game that may or may not be worth the fuss.

Well, the project started out as a simple video display application that woudl directly parse and convert motion JPEG. That was all the project was billed as at the start. So when i wrote it I didnt feel the need to over complicate it by makign a modular design. It started as maybe 100 lines of code so what would be the point. Well, after I finished that the boss springs the big banana on me and explains what the project is going to do, which still wasn tthat big a deal. I mean I had to break teh project into seperate .cpp files but that was it. Well, after we implemented his original method it turns out that while the program ran beutifully and executed his algorithm, the algorithm itself was flawed and didnt produce the results he wanted. So we mostly changed the algorithm keeping a few parts that worked. Again it ran great but the algorithm wasnt effecive. So this gets repeated about 12 times and you end up where we are and the architecture is so mangled that implimenting each new algorithm becomes more and more convoluted. Hind sight is 20/20 and had the algorithm we are tryig to impliment now been the first one we tried there ouldnt have been a problem, but the intermediate steps, with some of the code kept some deleted and some just not executed anymore has left it a mass of spaghettified flop sweat.

Oh and forget about the design document, there isnt one, and the last time I asked for one is the last time I will ask for one.

Originally Posted by abachler

Oh and forget about the design document, there isnt one, and the last time I asked for one is the last time I will ask for one.

Of course, there isn't one. You were the one that started the project and didn't define/request one. You decided there wouldn't be the need to re-equate the project in the future and went on doing something that suited your immediate needs.

Later you were told there was something more to it. Fair enough. That annoys anyone. But instead of taking the hint and starting fresh, you ended up in a snowball of code patching due to you not meeting the requirements that ended in this.

I'm sorry, but I only see you to complain about. It's ok though. We all commited the same mistake... several times.

I hate to admit it, but I have to concede that it was my fault. I have been programming for years, but this is the first major application I was on and like a fnub I screwed the pooch. Going forward I will make sure to get a requirements document up front and hold the customer and the boss to it unless there is a documented revision. By default I will make the applications modular so that those parts that may need to be modified and are specific to that application will be physically seperate from the project specific elements.

Do you guys have any other suggestions on how I can avoid this in the future? Any constructive criticism is welcome.