Occasionally, i'll see things i sort of disagree with. It's a familiar enough experience that you might have also seen such things.
Blinding flash of insights aside, there's a general philosophy among my peers in the tech community that it's important to rush out and prototype ideas early, so that they can be rapidly iterated upon and a great application rolled out. That's absolutely fine, provided there's one thing that's well known: You know what the hell you're building.
i mean, sure, if you're building a calculator or a photo editor, it's pretty simple to figure out what you're going to need at a basic level, then iterate and improve to get something that works well enough. There's a clear endpoint, even if it's only implied by your "SpiffyPhotos" app name.
If you're building a service, however, that may not quite be the same thing. Take, for instance, the idea of "Notifications". Sure, you might have an idea of what those are, but is it the same idea that other folks on the team might have? You might mean messages delivered to an end user, but how soon? What format? Is there an archiving or offline feature? How would discovery and association be done? Would this replace existing systems or supplement them? What sort of security issues would need to be addressed? And those are only the start of the questions, there's also the "who's going to pay for this?" and "How will this system be upgraded after it's deployed?" type questions that hang out there.
Yeah, a service isn't quite the same as a program, and there are a lot of things that it's far too easy to wave your hands at.
That's not to say that once you have the idea of what you're building, you shouldn't do the same rapid prototype, iterate, and improve model that's popular with kids these days. Just that it's far more important to actually understand what the hell you're building.
Personally, i kinda blame word problems for this. See, word problems, the bane of most kids math experience, often phrase problems in crappy ways. "If Bobby has two apples per hectare, and Jimmy has three apples per acre, what is the mean of their production over a ten year cycle?" or some crap. Those tend to be frustrating because you're spending an inordinate amount of time trying to decipher the variables rather than solve a problem. Real problems usually have far simpler descriptions: "Jimmy needs to build a bridge across a 10' wide chasm. The bridge must be able to support a load of up to 12 tons, and access to the heavily forested area is limited."
Same's true with a lot of other problems. Including the one at hand.
i think that folks need to be taught how to solve problems better. They need to understand how to look back, scale what the actual issues are, determine the variables, ask the right questions, and determine which are the better courses of action to take. (Note the plural, because as anyone who's dealt with problems will tell you, always have a backup plan.) This is remarkably hard and even some of the best, brightest programmers will tell you that they suck at it. (i'm hardly best or brightest, so i know full well i suck at it.)
In the case of "Notifications", what is really needed? Do you need to have something shove itself in front of the user, or do you just need a way to remotely wake an app so it can do what it needs to? Does the world need another chat app with yet more segmentation of a users association lists, or is there some other approach that might be more useful? i'll note that Flickr came about because the company that created it wanted an easy way to share photos inside of the game they were building.
In programming, there's a joke that trying to program is like teaching kids how to tie their shoes, only the first question you ask is: Do you have feet?
Sadly, i think there are a bunch of folks who are confused why their brand new virtual Keds aren't quite fitting onto their metaphorical tires quite right.