3 ms·
The classic on this kind of overengineering is Spolsky's architecture astronauts essay[1]. Which also describes another way to go wrong --- getting so lost bui
by rst 16y ago
The classic on this kind of overengineering is Spolsky's architecture astronauts essay[1]. Which also describes another way to go wrong --- getting so lost building general structures that you actually lose track of the problem that you were originally trying to solve: "... then they'll build applications ... that they think are more general than Napster, but which seem to have neglected the wee little feature that lets you type the name of a song and then listen to it --- the feature we wanted in the first place." Worth a read.
[1] Whole thing here: http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html
- joezydeco 16y agoEvery OO horror story I've ever been involved with has that same phrase in there somewhere: ...it does not allow us to select the algorithm we wish to use at runtime I'm an embedded programmer so this kind of thinking is alien to me. But really, everyone plans for runtime configurability but is it really needed that often?
- axod 16y agoOnly if you don't know what you're doing and need to write several algorithms that you can try out at runtime :/ It's an absurd use case IMHO
- kenjackson 16y agoThis simplification is just as wrong as the blog post. It's very common to invoke different algithms based on specific instances of the data. To give a baby example, its typical that one uses a different sorting algorithm as a function of size and data distribution and key type. Theres a popular fft package, FFTW, that is based on this as well.
- axod 16y agoI wasn't saying that you can't use different algorithms based on inputs/data/circumstances. The issue I have is articles like this always try to make things stupidly configurable and general - like "I want to be able to hot swap this algorithm at runtime".
- limmeau 16y agoIn Java, there is not much space between hard-coding dependencies and implementing patterns which (also) make algorithms exchangeable at runtime. The first makes unit testing difficult, the second makes you look like a StrategyFactoryFactory fetishist. Often, link-time configurability would suffice, but that is hard to achieve with Java.
- arethuza 16y agoI think Benji Smith's "Why I Hate Frameworks" rant is even better: http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12 http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
- raganwald 16y agoAs an aside, the other thing I love about Spolsky's post is that he was exactly right about something: Apple focused on giving people a way to type the name of a song and listen to it right away and iTMS was a runaway success.
- gdulli 16y agoNo one chooses to use iTunes. You're locked into it essentially if you buy an iPod. iTunes is a success because iPods are the shiniest players.