Fog Creek Software
Discussion Board

Most depressing thing: False starts and restarts..

One thing I can't stand is getting to a certain point in a project and realizing that there were fundamental mistakes made in some design decision or some assumption was made that was proven wrong.  As a result, large parts of the project have to be done.

So question:  What's the farthest into a project you've ever been before realizing you've made one of these doozies?  And how'd you handle it?  Did you pretend nothing was wrong and move forward or did you suck it up and start back from square one (or near square one)?

Monday, September 22, 2003

I would say the latest I have seen is done.

Most projects underestimates the complexity of the design process, and not only technical design, but also "vision management" if you will.

I have been in only one project that hit the target 100% with customer satisfaction being also 100%. We had tedious "what do you mean by saying X" workshops to no end to iron out all the expectations. The customer knew what to expect, and the techinal team knew what to deliver. This may sound retarded, but that is very seldom the case.

This got rid of the "oh, when I said potatoes I meant mashed potatoes not french fries" type problems which is common to go on the todo-list for version 1.1 released a few weeks or months later.

Most design misstakes are like these, not major showstoppers.

Monday, September 22, 2003

I suspect I'm not going to answer this question in the way you expect.

The situation you describe is the result of Big Design Up Front.

By doing BDUF, you convince yourself you have to make these decisions early in the project. Most of us use the mantra of "late changes to design cost more" to justify doing it. What we don't realize is that that mantra was created by automobile product line managers and it's not even true for them any more.

In the manufacturing world, JIT (just in time inventory) works by limiting irreversible decisions. In other words, don't make those decisions that force a particular development path on you until the very last moment. The same is true for software. Don't make those design decisions until you have to. Give yourself a chance to learn about the problem you're trying to solve before you make a decision.

Monday, September 22, 2003


It doesn't really have anything to do with Designing Big Up Front vs Agile vs anything else.  It's a matter of making a fundamental mistake or assumption up front, followed by going a long way towards implementation, and finally being forced to either roll back the clock to fix it...or cover it up (though, I know no here would *ever* do that. :) ).  That can happen no matter what process you use.  Basically it's when chinks show up in the armor of whatever process you use.

Monday, September 22, 2003


Agreed.  Many upfront mistakes aren't showstoppers necessarily, but it's still kinda depressing to have to go back and rip out a big chunk of code (especially if you did something kinda cool in that now worthless code).

Monday, September 22, 2003


I feel your pain. Producing cool code that goes unused is the least rewarding of all.

Unless your cool feature shoots completely off target, maybe you could talk to your customer.

What Im trying to say is that if the functionality you are now pulling is workflow related it might be worth to the effort to talk to the customer and have them evaluate the new way of performing a task.

Sometimes changes that requires a change in how the customer works gets pulled for no reason, other than an unwillingness to change.

Monday, September 22, 2003

Try to stay emotionally detached from your code, for  a start.  I used to have issues about throwing away a chunk of code and replacing it but not anymore as I've shifted to the "build one to throw away" mindset.

Keep in mind when I'm talking about throwing out a chunk of code, it is in a different context than Joel's "Never Rewrite" rule as I'm talking about pulling some code out I wrote yesterday, not code that has been patched up over the years and has been proven in real-world use.

You can't always expect to get it right the first time, and you're doing pretty well if you get it right the first time some of the time.  Once you accept that, it gets easier to rewrite a flawed first-try implementation without feeling bad about it.

Mister Fancypants
Monday, September 22, 2003

Code that doesn't meet the requirement isn't cool.

Code, and by extension architecture, may be  elegant outside of its specific utility and because it doesn't fit a particular scenario doesn't mean the time was wasted in creating it.

Just as software doesn't rust, neither do algorithms nor designs.

But if it ain't right replace it.  It has no feelings,  it doesn't support dependants, children through university or aged parents with Alzheimers.

Simon Lucy
Tuesday, September 23, 2003

You get to do designs? Think yourself lucky :-(

Tuesday, September 23, 2003

Use the component approach as much as possible and design/build components as generically as possible,
have their interfaces to be really general-purpose ones. Then build the whole thing out of those components. If requirements change there will be a lot less code to throw away, plus the integration will be a piece of cake. I tried this on many projects.

Serge Serguienko
Tuesday, September 23, 2003

Someone on here recently reminded me of Dijkstra's saying - "lines of code are not an asset, they're a liability".  I find that keeping that in mind helps me not to feel so bad about chucking something sub-optimal away, even if I did think that it was cool when I wrote it.

Wednesday, September 24, 2003

*  Recent Topics

*  Fog Creek Home