This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/10/were-building-the-space-shuttle.html
One clarification: I don’t think this behavior is limited to “beginning programmers”, either. We all do it, to varying degrees.
I guess it’s more glamorous to think of yourself as a software developer on a critical mission to build a highly complex, mission critical space shuttle system, but it just ain’t true 99.99% of the time – and I think our software would be better if we disabused ourselves of this mindset whenever possible.
Looks like that’s Linus Torvalds’s philosophy as well (answer to the 3rd question): http://www.linuxtimes.net/modules.php?name=Newsfile=articlesid=145
Excellent link. Torvalds:
“So start small, and think about the details. Don’t think about some big picture and fancy design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to jump in and help you. That’s not how these things work. You need to get something half-way useful first, and then others will say “hey, that almost works for me”, and they’ll get involved in the project.”
This is one reason, actually, I don’t care for Microsoft’s “Enterprise Application Blocks” (fex: the exception handling one.) They attempt to do too much for too many and end up disappointing on specifics.
I agree with the KISS principle, but not sure I agree with minimalistic as a mantra … a design needs to be sufficient to meet the needs of the system as well as the requirements (needs are not always explicit), but design decisions do need to be business-justified … it’s an oversimplification to say everything should be minimalistic in my opinion, because that either ignores the concept of quality altogether, or implies that there is some asthetically “correct” amount of quality … if the former, then you end up with model 0 PHP pages, in the latter you end up with developers thinking they’re artists who can self-justify the level of quality … for non-trivial systems, architecture plays a role in ensuring business outcomes (independent of how lightweight the methodology), especially if you don’t have a hoard of superstar programmers … on a non-trivial project, just being minimalistic is likely to leave you with a bunch of puzzle pieces which might or might not realize the big picture.
Thinking you’re building a space shuttle and using design patterns are two different issues. That’s not fair to imply that he who uses design patterns must think he’s building a space shuttle. Keeping it simple can include using design patterns. Design patterns aren’t making the simple complex; they’re about experience reuse and doing things in a proven way.
When I am asigned a programming task, I dash off the smallest, most expedient piece of crap software I can whip out. When they give you an assignment, always pretend that it is due at the end of the day instead of a month from now, and hack something together quick. I won’t even begin to pretend that I am an above average programmer - I’m just a hack schmuck who slops out crap for my who-gives-a-shit-anyway company. Having said that, I do like to collect shortcuts of how to do things, and I spend a lot of time reading programming manuals. You never know when one of the 16,000 available PHP functions might come in handy.
But I live in Huntsville, AL… so I know a whole lot of people who ARE building a space shuttle.
Offtopic pedantic remark:
“fex”? C’mon man. It’s better than misplacing i.e., but seriously when did Latin become Bad?
You forgot something… NO REDUNDANCY
In your post there’s so much redundancy, one wonders what you know about all that…
“Oh, I’m going to write the world’s best calendar control! It’s going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other.”
I’m crying right now because I’ve done this. It had recurring events, collision detection, hierarchical event categories, the whole shebang.
It’s a world of hurt.