*
programming and human factors
by Jeff Atwood
*
Today's dose of YAGNI comes from a recent Anders Hejlsberg interview:
If you ask beginning programmers to write a calendar control, they often think to themselves, "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." They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They'll think, "In the next version of the application, I'm going to do so much more."Once they start thinking about how they're actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they've painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I'm a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don't try and put in place a framework for solving a specific one, because you don't know what that framework should look like.
I've run into so many software developers who delude themselves into believing they're building the space shuttle-- instead of the crappy little business apps they're actually building.
One sure way to make your crappy little business app even crappier is to build it like you're building the space shuttle. I know, because I spend far too much time refactoring these spectacularly failed space shuttle missions into something resembling a supportable business application.
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.
Jeff Atwood on October 25, 2004 12:54 PMLooks like that's Linus Torvalds's philosophy as well (answer to the 3rd question): http://www.linuxtimes.net/modules.php?name=News&file=article&sid=145
DeepDarkSky on October 26, 2004 2:50 AMExcellent 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.
Jeff Atwood on October 27, 2004 2:14 AMI 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.
Bob Horn on March 4, 2007 9:21 PMWhen 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.
George C on June 30, 2007 8:33 AMBut I live in Huntsville, AL... so I know a whole lot of people who ARE building a space shuttle. :P
Allied on September 24, 2007 6:41 AMOfftopic pedantic remark:
"fex"? C'mon man. It's better than misplacing i.e., but seriously when did Latin become Bad?
dude..
You forgot something... NO REDUNDANCY
In your post there's so much redundancy, one wonders what you know about all that..
| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email