Fog Creek Software
Discussion Board

Second guessing my designs

I find myself second guessing my designs all the time.  Essentially, I spend too much time on my up front design.  While this may sound like a good thing, I think I'm overdoing it.

My first job out of school was in a very antagonistic environment - everyone was critical of everyone else's code.

Even though I've moved on to another job, it's had a lasting effect on the way I code.  Instead of just concentrating on the problem, I ask myself how my peers would judge my design and code.

In short, I'm coding for my peers' esteem as much as I'm coding for my customers.  I don't think this is mentally healthy or productive.

Constructive comments? ...

Thursday, August 26, 2004

Constructive comments? No. But some sympathy here. I'm doing exactly the same...

Thursday, August 26, 2004

I know you've heard this a thousand times before, but K.I.S.S.

Do nothing more than what is required by the customer.

Once you've got the minimum requirements completed, go back and add all the fancy features and implementations that you want.

Thursday, August 26, 2004

Try eXtreme Programming

Thursday, August 26, 2004

what does xtreme programming have to do with designs?

Thursday, August 26, 2004


eXtreme Programming aims to eliminate most of the design process altogether. The basic concept, if you haven't heard, is to "create the smallest thing that could be useful", then evolve it over time into something complex and unmaintainable, rather than designing something complex and unmaintainable from the get-go, and having to modify that design heavily when reality intrudes.


Mark Bessey
Thursday, August 26, 2004

Ultra-Hype Haxoring is the latest and greatest.  It involves a million code monkeys randomly banging the keyboard.  Studies show it is 58% more effective than extreme programming.

Thursday, August 26, 2004

Ultra-Hype Haxoring is the shiznit. Given enough time, a million code monkeys randomly banging their keyboards will develop the next killer application.

Thursday, August 26, 2004

read the book <Code Complete>
read the book <test driven development> by Kent Beck
read codes of some open-source projects

keep far away from some java-erp-mis-projects :)
never never say the something like "design pattern", "uml"

Thursday, August 26, 2004

It sounds to me that you are probably afraid to settle on a single design and move forward because your design may not be right and therefore you think you will fail.
Choose a design and move forward. You may fail, and hopefully these failures will be small enough that you learn from them and the next time you will do better.
Im betting this cycle will be quick for you and your designs will get better and better and you will be more confident in what you do.

Bite off a design and move forward. You can do it !

James Ladd
Thursday, August 26, 2004

"Once you've got the minimum requirements completed, go back and add all the fancy features and implementations that you want."

Huh?  This idea is way too close to writing new code before fixing bugs.  We all know the truth is anyone who actually "gets things done" will never go back and add fancy features.  If the customer is satisfied, you probably have more customers waiting for their projects to be done.  Do you think they want to wait for you to go back to your dogfood and add features, when the old customer doesn't even care about them anyway?

To summarize the best advice so far: focus on the customer's needs, do your best to design the best solution, take ownership of that design and run with it.  Yes, you will look at the design and code later and see inefficiencies and areas for improvement.  This is the process by which we learn to be better.  But getting better should not keep you from getting things done and keeping yourself moving in a forward direction.

Clay Whipkey
Thursday, August 26, 2004

Overclocked, you need a reality check. Try and code your own design; see what it feels like. You're better off if you cycle frequently (every month or so) with every cycle ending in a demo.

If you make design mistakes you'll catch them right away. And you'll be dealing with concrete problems most of the time; therefore you won't have to second guess your design any more.

At the end of every iteration, check the quality of your design and how well it covers the short & long term goals. When you find your design is broken, refactor mercylessly.

Friday, August 27, 2004

Why not try asking some of your colleagues what they think?  They might spot things that you have not thought about. 

Friday, August 27, 2004

Alright, here's what you do:

(This was done on one of my first professional projects and it was amazing & enlightening.)

Take as much of your design as possible and start putting it on your whiteboard(s) in your office/cubespace where people are likely to see it.

Coders and other developers (there *is* a difference) will see it and tend to stop and look.  And occassionally ask questions.  Try to express your ideas to them and ask questions in response.

Either A) your explanations will get clearer and you'll gain more confidence or B) your explanations will sound like the crap they may be and you get some feedback.

Friday, August 27, 2004


Buzzword-Compliant NonLinear Programming is far superior to Ultra-Hype Haxoring!

Acknowledge the One Truth of Buzzword-Compliant NonLinear Programming, or I shall declare jihad and flame you without mercy!

Devon Grey
Friday, August 27, 2004

I outsource all my redesign work to these guys.

I suggest using Speedy if you can...

Friday, August 27, 2004

"Once you've got the minimum requirements completed, go back and add all the fancy features and implementations that you want."

"Huh?  This idea is way too close to writing new code before fixing bugs.  We all know the truth is anyone who actually "gets things done" will never go back and add fancy features.  If the customer is satisfied, you probably have more customers waiting for their projects to be done."

Actually, this is a process we've had to make one of our clients realize.  They come to us with a big project, and say "oh, by the way, our go-live is 2 weeks from today."  No choice but to say "OK, then we need to do it in phases, starting with the minimum functionality."  So fancy features aren't always the imagination of the developer running wild -- sometimes it's the client.

Friday, August 27, 2004

Overclocked -- I was doing the same thing for a while.  Then I eventually realized that there is no such thing as a perfect design.  Inevitably, someone will want to extend the project in a way you haven't planned for, and you'll have to go back to the drawing board (or resort to hacking it in and making a mess if you're too short on time). 

So now I just have a couple general designs I reuse (ie, this works well for thick-clients, this works well for web, etc).  Most of my projects tend to be very similar to each other, so as I do more of them, those basic designs evolve with my experience and become better.  But the important thing is that they get the job done without taking a ton of time up-front.

Friday, August 27, 2004

I was second guessing my designs so I developed a logical, systematic approach to design that would help reduce my second guessing.  However, I've found that I began second guessing the logical, systematic approach that was designed to reduce second guessing.  I was second guessing the second guessing reduction system to such a degree that I was actually able to get some things acomplished because I'd stopped second guessing the actual project and was second guessing the logical, systematic second guessing approach.  Howerver, I now find myself second guessing everything I've been doing because it's obvious that the logical, systematic approach used to reduce second guessing did not actually work, thus my other projects were probably not second guessed appropriately, but that's just a second guess.  The other issue is that the second guess may not be as good as the original guess (so to speak) so I really require a third guess.  But, honestly, I don't know if that's the best approach.

Hed Hertz
Friday, August 27, 2004

At some point you've got to realize two things:

1) It's easier to criticize existing work than it is the produce new work.

2) Within reason, this is true regardless of who's doing the producing and who's doing the criticizing.

Hindsight is 20/20 and all that.  Peer feedback can of course be helpful, but you (and others) will ALWAYS find things you wish you'd done differently when you're done.  You just have to accept this as gospel and move on.  Anybody with more than a couple years of team development experience should know this, and if they don't their criticism is moot.

And a favorite of mine, at the risk of being overly dramatic:

"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat."

Theodore Roosevelt

All that being said, over-designing is a drag.  Try a new approach: take a page from the over-hyped agile/extreme/whatever camp and don't design any more than can be coded in 2 weeks.  Re-work as necessary.  Repeat a few times.  See how that goes.

Ian Olsen
Friday, August 27, 2004

*  Recent Topics

*  Fog Creek Home