Thursday, February 12, 2009

Maneuverability and Sales

Two quotes to start:
"There's a sucker born every minute"
P.T. Barnum (1810 - 1891)

And more importantly:

"Up until maybe a year ago, I had a pretty one-dimensional view of so-called "Agile" programming, namely that it's an idiotic fad-diet of a marketing scam making the rounds as yet another technological virus implanting itself in naive programmers who've never read "No Silver Bullet", the kinds of programmers who buy extended warranties and self-help books and believe their bosses genuinely care about them as people, the kinds of programmers who attend conferences to make friends and who don't know how to avoid eye contact with leaflet-waving fanatics in airports and who believe writing shit on index cards will suddenly make software development easier."
Steve Yegge, Good Agile, Bad Agile (2006)

Sure Steve was a little harsh in that second quote, but there are three huge facts that people keep blindly skipping over lately:

- Programmers are a sizable market (with lots of money).
- There are lots of people trying to make their living exclusively from selling to programmers.
- Most highly visible people are visible because they are selling something.

Ultimately, this means that for many of the people who are outspoken in the programming industry, some of what they are saying is good. Some of it however, is just filler that they made up one morning in order to insure that their cash flow doesn't dry up.

You, the programmer are just another client, and they, the writer, author, consultant, adviser, or whatever other title they have, has identified you as being their potential customer. This means that they will tell you want you want to hear. If it's right, that is nice but it's not obligatory.

For all those people out there, saying with such confidence that person X said "blaa, blaa ...", you can't necessarily take what they said at face value. It might be right, but then again it might be wrong. And it doesn't matter if they've had an unbroken record of being perfect for twenty years, this latest direction could be entirely full of it. Since most of what they said in the past was subjective, that too, could be equally be full of it.

But a simple analogy might be more helpful. If you go down to you local mega-drug store, you'll find a huge number of products. Each and every one will have a label espousing it virtues, and many will make huge claims. Some of these products will, of course, work as directed, and the effects will be as described. But for many of these products, they won't nearly be as effective as their advertising. And for some of these products, they'll be down right misleading or dangerous.

This happens of course, because the really big drug store doesn't actually care about its customers. Sure they have a marketing campaign telling you they do, and if something goes wrong, it will ultimately hurt their bottom line. But they only really care about making money, not about helping people. Hurting people is bad if and only if it makes less money. It's not a terribly pretty ethic, but it is what it is.

For someone, anyone really, who makes their living through the promotion of ideas with regard to a discipline, the same is absolutely true. They are interested in good ideas, in so long as they make money and they can sell them. Good ideas that are unsellable, because they are "owned" by someone else, or they're too obvious, just don't have value.

Once a market gets established, the players all have vested stakes in making sure it continues. We certainly see this happening in programming, with a new (ish) wave of lighter processes selling a mass number of books, conferences, training, consulting and a whole host of other profitable spin-offs. It doesn't matter once it gets going if it makes sense anymore, that's no longer the point.

It's easier in a immature discipline like software development, since most of what passes for advice is subjective rules of thumb. People don't know, so you can state anything that sounds plausible, and make a reasonable argument. Of course, being subjective as it is, it certainly by definition isn't going to make a huge difference. If it did, then it would be objective, irrefutable and quite possibly unsellable. That's just not profitable. If it worked as advertised and solved all of the problems, it would dry up the market wouldn't it?

Of course, most people selling aren't that petty. But even if they aren't particularly out to get you, there not necessarily out to help you either. They're out to make a living, that's what is important to them. And those motivations make it really easy to step on their toes. Often with negative consequences.

You know you are really dealing with something questionable when its practitioners defend their subjective claims mostly by means of personal attacks. That's the ultimate low point. A common defense is to state that if you haven't "done X", then you can't possibly have a valid counter-argument. Nonsense of course, as we humans have great imaginations and understanding, which often allow us to truly understand things even if we personally have not experienced them. A claim, of any type should be able to stand up to a few though experiments, if nothing else. Good in theory does not mean good in practice, but the converse isn't necessarily false. If it works, you can talk about it, and understand it, even if you've never experienced it yourself (the only real case where you can't is emotions). You can always generalize from the real world, you just might not be able to compact it enough.

Things that are good, are intrinsically good. They will stand up to argument, and they can be discussed even if it's hard to entirely rationalize their substance. Sometimes things are good in a specific context, but don't generalize well. A time or place may have contained other ingredients that aren't properly being account for. Still, its worth investigation to really see why the reality differed from expectation, usually that is a sign of something else lurking about.

Sometimes the right answer is not the immediately obvious one. Sometimes an answer is marginally better, but still not good. Sometimes it takes a long long time to work through all of the bad answers first.

The road ahead in software development is filled with an untold number of bad theories and false starts. That's the inevitable truth in any maturing discipline, yet it's one that many software practitioners seems unaware of. Just because something is appealing or sounds good, doesn't mean it is good for you. That's obvious in food -- chocolate cake for breakfast every morning will eventually kill you -- but it's also true in programming practice. The best one can expect is that we take some time to think about each new approach, and if necessary try it out somewhat. Buying into everything, at the 100% level is a recipe for disaster. The goods being sold are just not that reliable.

So what about me? The truth of the web is that if you take a hard stance on an issue, you better expect to get some negative feedback, and in our industry they'll go for the throat. I'm not out to interfere with anyone's right to make a living, I'd do so myself if I thought I could write and lecture well enough. But I don't, and I don't think people should take what I say at face value either. I just put it out there to get the discussions started. It's important, I think, that we take a hard look at what we are doing, and really genuinely explore what we know and the alternatives. The only thing I am really sure of, is that we haven't found it yet, whatever "it" is.

I really do think that so many programmers expressing their popular opinion in blog comments have forgotten or have never know about "Caveat Emptor "; Latin for "Let the Buyer Beware". No one in their right mind would advocate Coke as a medicine because of their slogan "Coke adds Life". It's a soda pop, we know to take their marketing claims lightly. The truth in the software industry is that much of what passes for industry best practices, old and new, isn't much more trustworthy than a Coke commercial. It sounds nice, and it helps sell. So, it's very disconcerting when people quote it like gospel. Getting back to my earlier example, just because a big drug store sells it, doesn't make it work. Most people know by now to be skeptical in a drug store.

When the pundits are pounding each other back and forth over issues, never forget that you are the buyer -- this show is for you -- and that some of what they are saying isn't worth paying for. There is good advice buried there, but you can't utilize it effectively if you're unwilling to admit that some of it is crap as well. Don't take the marketing on the package literally.

6 comments:

  1. I'm surprised this post hasn't triggered a discussion.
    I myself is currently "trying out" (has been for several years now) Scrum as a software development process. In theory I love it, so simple, so beatiful. In practice though, we're struggeling a lot. I guess most our problems are people-related though, and that's something I think no methodology can help me deal with.

    ReplyDelete
  2. Hi Hans-Eric,

    I thought it would at least get a couple of responses, but I don't seem to have many talkative readers as sites like Coding Horror.

    I think it's great that people are experimenting with all new types of processes. The only thing that drives me nuts is when they become defensive and refuse to admit that there's any downside at all. Progress only comes from knowledge (and we really need progress :-) I'd hate to miss the next innovation just because the packaging was too hard to deal with.

    At the very bottom, if you can just get people to do things a little more consistently, and not be overly protective about their code, than you can always change and grow overtime. My guess is that a better methodology would reduce people-related issues by providing less opportunity to step on each others toes. The process is what should keep the people from banging into each other while using the tools.

    Paul.

    ReplyDelete
  3. I think Hans-Eric made a good point, a lot of it really comes down to people. Process is great and all, but the process only works if people commit themselves to it, and commit themselves to the team. I think people should always come before process, because people are what get the job done, not process! I think the good companies understand this, and aren't afraid to break the process when it is clearly affecting their people in a negative way. I think people like DeMarco and Spolsky understand this; it must be nice to work for them.

    I also, until recently, saw the term Agile as another buzzword to be added to the list. However, after a little reading, I'm starting to think that true Agile practice is about doing what I just talked about. That is, putting people first, and process second. I like it's notion of constant feedback and low economy process. If something is too heavy then it is quickly broken down! Basically, don't get yourself in a death march. There are a lot of processes attached to Agile, but I think it's the mindset, above all, that separate it from other methodologies.

    All that said, I do agree with you, Paul. Everyone one should be critical of what they are told. Just because Joe Blow, or Donald Knuth for that matter, said it was good does not a good thing make. I learned this lesson the hard way a couple years ago while preaching the Gospel according to Joshua Bloch (aka Effective Java) to my co-workers. I would blindly quote Bloch whenever I saw the occasion, and would scold my co-workers for doing anything opposing his methods. The problem was, I could never explain, in my own words, why his methods were good. I took what he said as the absolute truth. These days, I figure if I can't give my own reasoning why something is good or bad, then I should probably hold my tongue.

    FYI, I've been reading your blog for quite some time. It's quite enjoyable. Your content is normally very high quality, but there is only so much I can handle it one blog post. I was happy to be able to read this one in a matter of minutes. This length is much more palatable. Keep up the good work.

    ReplyDelete
  4. I think Hans-Eric made a good point, a lot of it really comes down to people. Process is great and all, but the process only works if people commit themselves to it, and commit themselves to the team. I think people should always come before process, because people are what get the job done, not process! I think the good companies understand this, and aren't afraid to break the process when it is clearly affecting their people in a negative way. I think people like DeMarco and Spolsky understand this; it must be nice to work for them.

    I also, until recently, saw the term Agile as another buzzword to be added to the list. However, after a little reading, I'm starting to think that true Agile practice is about doing what I just talked about. That is, putting people first, and process second. I like it's notion of constant feedback and low economy process. If something is too heavy then it is quickly broken down! Basically, don't get yourself in a death march. There are a lot of processes attached to Agile, but I think it's the mindset, above all, that separate it from other methodologies.

    All that said, I do agree with you, Paul. Everyone one should be critical of what they are told. Just because Joe Blow, or Donald Knuth for that matter, said it was good does not a good thing make. I learned this lesson the hard way a couple years ago while preaching the Gospel according to Joshua Bloch (aka Effective Java) to my co-workers. I would blindly quote Bloch whenever I saw the occasion, and would scold my co-workers for doing anything opposing his methods. The problem was, I could never explain, in my own words, why his methods were good. I took what he said as the absolute truth. These days, I figure if I can't give my own reasoning why something is good or bad, then I should probably hold my tongue.

    FYI, I've been reading your blog for quite some time. It's quite enjoyable. Your content is normally very high quality, but there is only so much I can handle it one blog post. I was happy to be able to read this one in a matter of minutes. This length is much more palatable. Keep up the good work.

    ReplyDelete
  5. Hi rzezeski,

    Thanks for the comments. I'm always glad to hear my long-term readers; sometimes I worry that I am talking to myself :-) As always, I'd make the entries shorter, but I (irrationally) fear becoming entertainment and once I start writing I find that I just have way more to say (oddly, I'm actually fairly quiet in meetings). Still, sooner or later I'll have to give up the long entries (they just require too much time).

    It's certainly true that some of the worst processes I've even seen, like matrix resources, come from ignoring people and their individual issues. Still, if you get a big group of people together with little or no structure, the differences in opinion will hold them back. To get as much as you can from them, they need to be clear about their roles and what they are doing with respect to the whole. A good process shouldn't hold good people back and it should help everyone contribute.

    A key element I've found is for a development process to contain a way around the process itself -- a fast track. Mostly the "right" way should be followed, but if that's not going to work, then a fallback to a fast track (and technical debt) can happen. Accepting that there are two ways to do things works wonders.

    Agile's greatest contribution is that unlike many of the older methodologies, it realizes that the deliverable is actually code, not paper. That's actually a huge leap forward.

    Paul.

    ReplyDelete
  6. Good point. I didn't mean to totally abandon process. That certainly would lead to chaos. However, the process, just like a design pattern, should come from recognition of a repeated sequence that seems to often lead to good results. You also need to be able to recognize when a traditionally good process, has become obsolete or irrelevant. There are people who preach certain processes just to cover their behinds, or because they are too afraid to try something new. We cling to what we know, and anything unknown is scary or even wrong! Part of Agile, the way I understand it so far, is the ability to recognize quickly when a process is hindering your progress and to take action to remove the bottle-neck.

    Also, like Spolsky says, it helps to have people that are "smart, and gets things done." You can train a monkey all you want, but at the end of the day he's still a monkey.

    I like your last point a lot. I'm in an "Agile" shop right now, but they produce piles upon piles of useless documentation. It's all for internal products and pretty much no one reads it. It's basically write once, read never documentation. Meanwhile, time lines are slipping and yet they still feed into the documentation frenzy. The waterfall model still lives, even after a shop calls itself "Agile."

    ReplyDelete

Thanks for the Feedback!