Nuggetty Goodness

You've taken the prevalence of bad analysis and design practices as evidence that they simply don't work. Doing it correctly requires a deep understanding of the problem domain, of the people who will use the product, and what technology can do. Yes, most practitioners are terrible, but it's brazen ignorance to state that analysis and design (requirements being the output thereof) are bullshit.

My experience with developers (and I include myself when I was one) has been that they are good at building things right, and not so good at building the right thing, except in the narrow space of products that programmers use. They can build what they want, and they can build what a customer says they want, but they are not effective at listening to what a customer says they need and figuring out what that actually means.

Because most clients, if you ask them directly what they want, will describe a solution based on their own flawed assumptions about technology, and they often don't understand their own problem very well.

If your sales force is saying they need a new order entry application because the one they have is slow, and you take them at their word and start building one, that's just plain stupid. Maybe it is simply difficult for them to use. (They are sales people, after all, and they use the system infrequently.) Why the fuck are the sales people entering orders anyway? Is that something customer service can do? Can the customers enter their own orders? Your going in assumption should be that whatever solutions your clients propose are at best illustrations of some of their concerns and not the actual requirement. You have to look at their business, at what they do, at the people and processes surrounding it, at the larger context in which it all happens. Otherwise you're just wasting time.

My experience has been that people who can do this well are rare and they aren't programmers at the same time they are analysts. Many were programmers, and some may go back and forth, and on small projects it doesn't matter so much, but for complex requirements it is damn near impossible to keep both models in your head at the same time and retain the necessary objectivity. If you're thinking about the code, you're going to gravitate to solutions you want to build and not the solution best suited to the problem at hand. You need to be grounded in an understanding of what is technically possible/feasible, but at the same time you need to forget about that and pretend you have magic fairy dust and anything is possible. This paradoxical thinking tend to hurt your brain and the end result has to be something doable, but it allows you to explore a solution space much larger than a "what can we build" mindset will afford. There are some developers who can do both, but you don't get many opportunities to hire them.

In the consumer space, it is the same, just fucking harder still because consumers haven't got a clue what they actually want or what technology can do and if you only target those products that developers would use and understand, then you're severely limiting your target market.

Look at a company that does this for a living well and you'll see that it can be useful. Apple gets it. How their process works exactly I don't know, but I promise that someone is doing "business requirements" in the sense of thinking deeply about what problems they are actually trying to solve for who, and how the product will actually be used in real life. When I saw the iPhone for the first time, my immediate reaction was "Apple is going to make a big pile of money" because they were the first company to really nail the requirements in the cell phone market. Everyone else previously was just building what their developers thought would be doable/cool or under the sway of designers who didn't know what they were about.

Or if you want a more generic example of someone who at least has a chance of getting it right, look at Cooper design. They have some concept designs posted on their website that are, in my opinion, examples of what a "business requirement" should look like. Note that while the designs could be built, there's nothing in the requirements about how they should be built and there are some interesting business and technological challenges that would need to be overcome. I would suggest that many or most successful technology products (iPhone, again, for example) are the result of solving such interesting challenges and therefore one benefit of good requirements is that they can direct our attention to the problems worthy of solving if we want a successful product. Too often we invest time in optimizing or creating features that nobody actually cares about.

Anyway, aside from being completely wrongheaded and misinformed, nice post.

Comment from a long rant, "Stevey's Blog Rants: Business Requirements are Bullshit".

The rant is nonsense. It does what my title says - confuses poor analysis with a lack of need for any analysis.

The rant-comment though, is epic. ;)

Requirements gathering and the analysis that has to be done to come up with those requirements isn't the same as simply gathering data.

Data are the dots in an (unnumbered) connect-the-dots painting.
Analysis is drawing the lines that connect those dots into a bigger picture of a plan.
Good analysis means that the plan you've just come up with has a good chance of leading to phat lootz.

The user doesn’t come out of nowhere. We don’t land on your page and then head happily to those social networks to promote you, just because you have a button on your site. We find content through Facebook, Twitter, Google+, Pinterest etc., not the other way around.

• Whoever uses social networks to find content, usually begins the web journey there and goes back naturally. We don’t need to be reminded of what network we use on the way. We know. We came from there.
• For those who don’t use social networks the social media buttons are completely useless.
• If readers are too lazy to copy and paste the URL, and write a few words about your content, then it is not because you lack these magical buttons.

Some people probably do use those buttons. Maybe even a lot of people. And maybe you do and think I’m dead wrong about this. Maybe I am. And maybe someone needs to do some serious research to know for sure. I won’t deny all that. What I know for sure is that most people who know how to use social media also know how to share URLs:

“We removed FB buttons and traffic from Facebook increased. Reason: instead of ‘liking’ articles, readers share it on their timeline.” —@smashingmag

If you provide excellent content, social media users will take the time to read and talk about it in their networks. That’s what you really want. You don’t want a cheap thumbs up, you want your readers to talk about your content with their own voice.

This is too true!

In fact, although I have a Pinterest account, I do NOT use 'pin it' buttons. Ever. For some reason I am convinced that using the bookmarklet app gives me more control of exactly what goes on my Pinterest.

...now I'm wondering how that applies to other social networks, and other people.

Article also includes some disturbing info on what Those Cursed Bahtuns may be doing to your site.

More thoughts after discussion with a colleague:
Even if incoming traffic rises when buttons are removed... how do we (as webfolk) track and attribute the traffic sources?

Sure, if you've plonked banners all over the place, you recognise where *that* traffic was from. But stuff that people are sharing all by themselves over their own social networks?

When a user pokes a button on your site, you know about it.

When a user does what I've done here, which is to quote and provide a link back to the shinies... you, as site owner who wants to know, you have no clue what I've done.

And short of going through EVERY unfamiliar referring link to see where it came from... you'll never get those numbers. You'll never be able to track what people are doing / have done with your content.

Conclusion:
The buttons are there because without things to count, beansuits get twitchy.

Well now, that's depressing. XD

All the above being said, this is incredibly funny (don't click if you have epilepsy, and yes I'm serious).

Another interesting take on it. Text and safe for epileptics.