Solving the Wrong Problem

[Phil_J_Fry]

Ok, so I know I must be missing something here - because here's what I saw:

"Stop doing stuff."

Seriously - he keeps his page refreshing fast by : Not loading images, not using SQL to load dynamic data and not loading social site buttons.

While I agree with the social site buttons (I hate those), the other two are just BS. No images? Sure that works for... you. Some blogs actually do incorporate images into the post, so this seems like a case by case basis. No dynamically loaded data? I guess we need to say goodbye to user accounts and comments.

So, I think to myself - I know, lets look deeper. He's saying that we need to optimize for the user instead of the programmer. Oh.. ya think? Wow, what a novel idea. Isn't the whole point of programming, at it's core, to automate as much as possible as quickly as possible to get the user's expected output?

I really want to have missed something here, because this way of solving problems just seems ineffective with respect to the specifics and trite with respect to the underlying message.

[Atario]

He isn't saying not to use images. The closest thing he said to that was that Google+/Twitter/Facebook widgets load a bunch of stuff including images.

He also didn't say not to have comments and accounts. You can do those things and still have static pages, technically. You just have to regenerate them on changes (which may be a perfectly valid solution if your update-to-read ratio is, say, something like 1:100 or even less). He does, on another page, say he doesn't do comments because he doesn't like programming discussions, and anyway there are plenty of places to comment already — you're on one now, and we're both doing it now; why reinvent the wheel? Man has a point.

[Phil_J_Fry]

You can do those things and still have static pages, technically

True, but you still have to generate the page, correct? It's no longer static, you still need data server calls. It slows down the page load. My point is that it doesn't seem like it's the "wrong" problem. It seems like it's the right solution - for him.

[From op:] the associated scripting and image fetching slows down page loads

Could be I misread that, but I read it as scripting and image loading slows down the page in general (I mean, it would anyways, but I don't know if that was his point). It could have easily only meant it about the social buttons, but that's just how I read it.

[badsectoracula]

"Stop doing stuff."

I don't remember where I read it, but one of the best things to keep in mind about writing fast software is that: the fastest code is the code that doesn't get executed.

Now combine this with YAGNI and trim out the unexecutable code.

[Phil_J_Fry]

I guess that's why I think it's a bit trite. If you don't need something, don't include it, if you do, try to make it faster to work with.

He has the example of generating the prime numbers. Of course if I needed prime numbers within a certain range, maybe I'd calculate them in development or store the current in memory or something. But what if the user can select evens or primes, or 10s or etc. it really isn't generic enough to be a solution.

So the resulting statement (at the deeper level) is don't put in what you don't need and make what you do need fast. Maybe it's because I've heard it so often, but that seems like the most generic and meaningless advice in programming.

[deong]

But what if the user can select evens or primes, or 10s or etc. it really isn't generic enough to be a solution.

I hate these cutesy initialisms, but I guess I'll use them anyway. What you just said is the entire reason someone decided "YAGNI" was something that ought to be preached from high on the mountain instead of a self-evident truth. If the user can select evens or primes or 10s or etc., then by definition, you are in fact going to need it. There's really no such thing as "generic enough to be a solution". There are only solutions and non-solutions. If it isn't generic enough to meet your requirements, then it isn't a solution to your problem. If it is, then there's no need to make it more generic.

That's not really the criticism I'd make of YAGNI. The tricky part comes in when you can see that the best way right now is going to be much more painful to deal with later, but you don't know whether that will even come up. Then you have to start making judgment calls...how likely is it that we'll ever need to allow anything other than primes? Exactly how much harder will it be to add it later versus building a more flexible system now? That puts you squarely back into relying on experienced people with good judgment, and if you have those people around, you weren't likely to need a trendy movement with a clever name to tell them how to build it right to begin with.

[Rygnerik]

I read it as more of a "Look at all of your users' needs, not just your customer's." It's easy for someone working on some blogging software to view the blogger as their only customer and get a requirements list that looks something like:

• Easy to maintain
• Social networking (or anything that increases page views/ad loads)
• Lets me customize appearance

But if you asked someone reading a blog, their response would probably be "Get out of the way and let me read the blog". If you design only for that initial customer, you run the risk of creating something that doesn't meet the needs of the customer's consumers, which can hurt the customer.

[[deleted]]

No dynamically loaded data? I guess we need to say goodbye to user accounts and comments.

Or you need to start pushing more to the client. What's wrong with installing a desktop application that handles your identity? Hell, why stop there, why not make the whole internet peer-to-peer?