Monday, September 24, 2007

Blogger Credibility: No Easy Solution

A while back I read a post by Joel Spolsky entitled Bribing Bloggers. The focus of the post seems to be deciding whether or not giving away free products to people to do reviews on them is ethical or not. Joel was approached by a large software vendor with an offer of a free laptop loaded with one of their latest products in the hopes that he would blog about it. The terms of this gift were that it was up to the recipient as to whether or not they even wrote about the machine/software product and what to do with the machine afterwards with suggestions being: keep it, return it or give it away. Joel is of the opinion that "... this is ethically indistinguishable from bribery. Even if no quid-pro-quo is formally required, the gift creates a social obligation of reciprocity."

I'd have to disagree, especially if there is no quid-pro-quo required. I don't know of too many companies that go around handing out money to government officials without expecting something in return. Sure, they say they don't. "It's just a campaign contribution." But you don't see companies contributing to officials that don't have a history of voting in the interests of that company. There definitely is some scratching of backs expected there.

In situations like this, I don't think there is anything wrong with giving away products. I don't base the credibility of any blogger whose work I read on how they acquired the item to be reviewed. Did they write the software themselves? Did Evil Co. give it to them? Or did they go out and spend $2,999.95 of their own money on Benevolent Ltd.'s latest whatsamajigger. There's always an angle. The trick as a reader is knowing what the angle is and how it affects the viewpoint of the blogger. If you can't live with what you learn, find someone else to read.

So what have we learned? The credibility of a blogger might start with how they behave in various situations. But it ends with each reader deciding for themselves how far to trust each blogger on different topics in different situations. Let me say that again. It is ever so much more importanter that each reader decide how credible each blogger is. There could be hundreds of reasons why they write the way they do. If a blogger thinks that means they can not accept free products from companies with vested interests in those products, so be it, but that is no more important than knowing that ease of use is more important than versatility to the blogger you're reading.

Example 1) Joel seems to like Benevolent Ltd.'s products because they are incredibly usable. Not bad criteria when looking for items to purchase. Personally though I always find myself thinking "Benevolent Ltd. hasn't made a(n) [insert product here] that has accomplished all the tasks I would ask of that [insert product here] since the mid-eighties. But I can buy another company's [insert... blah blah blah] that is more-or-less equivalent. Maybe it is not quite as easy to use or it's not as pretty. So what. The color might not be the exact shade of white that I like and it may take an extra step to accomplish the task I want, but it does do everything I want and I can even change the batteries. All for a better price point. Who the heck would like Benevolent stuff? Must be zealotry." I do realize this puts me in a severe minority most of the time and my opinions differ with this particular blogger. But I already know how far to trust each blogger on various topics because I've read so much of what they have to say and figured out how far to trust them.

Example 2) This is a more hypothetical situation. A blogger may only post positive reviews of products. Does that necessarily mean that blogger is a corporate shill? Or did that blogger choose to write only about products they want to endorse and skip the bad ones. Maybe they were trying to create a "What's Hot" sort of feeling and save their readers from the "What's Not" negativosity. Again, knowing how the blogger's values compare to your own and knowing the blogger's track record is what's important.

I suppose I am writing a response to this because Joel's piece came off a bit snooty and condescending to me. It is always possible that I don't have the same view as Joel because no one reads my blog and I have never been offered a free product to gab about, nor have I been accused of selling out because I blogged about a piece of hardware that I just really liked. Fair enough. A quote from Joel, "Effectively [the company has] bought publicity and goodwill. And even though the blogger has fully disclosed what happened, their message is corrupting the medium." Corrupting the medium? The medium of blogging is already as far gone as the Internet in general. Can it really be corrupted anymore? Some broad sweeping marketing campaign by Evil-Benevolent, Co., Ltd. is not going to change my opinion of any blogger, good or bad. Only that blogger's reaction to said promotion will change my opinion of the blogger. Didn't we have this credibility problem before vendors started giving away freebies to bloggers? Can a blogger not be trusted to write an honest review just because the topic item was a gift? Are bloggers just not able to tell the truth and not suck up if they accept a gift? And most importantly, can readers not be trusted to pick out the intelligent, socially responsible bloggers from the corrupt?

And in the end, the company sort of got what they wanted anyway. They may not have gotten a favorable review, but Joel did mention their name and products. And even though I disagree on this topic, Joel still seems like a pretty smart individual, I know another topic on which our opinions differ and I continue reading his blog.

Tuesday, September 18, 2007

Organic Software Growth: Watch Out For Cancers

One of the concepts that the company I currently work for touts from time to time is that their code grew organically. I'm not exactly sure what the president of the company understands the meaning of the word "organic" to be when used in this context. There are times I think that the word is simply thrown around as a buzzword because a bunch of really smart developers see the potential in it to help solve some of the large design and architectural problems that developers face on a daily basis.

And it does seem that organic software growth can be a great thing. If by organic growth you mean that when you respond to the demands of your customers you are able to increase the functionality of your software by growing new features into the the existing structure of the application in a way that is consistent and usable. I imagine this like those pesky spider plants all over the office. When they grow, you know what to expect. You get more fresh air and they are more pleasing to the eye simply because they got a little bigger and another leaf sprouted or whatever it is that individual leaves do. And with a little bit of daily tending, they really aren't all that pesky.

What you don't get is an ear of corn on your spider plant all of a sudden. This might not be a bad thing at first. You will certainly get your five minutes of fame for discovering or creating this new organism. People will be able to have a couple pieces of fresh corn at the office every once in a while. However, people will eventually realize that the two or three ears of corn they get from your new spider-corn plant really isn't worth all the trouble of having to re-balance the hanging pot every week so the water doesn't run out. Oh, they also have to make sure the pot is in a place where the corn ears get a lot of light but the spider part doesn't get so much light that it shrivels up. After the week or so it takes to find these problems, your customers will go get their spider plants from WalMart and buy however much corn they want from la fruiteria down the street whenever they want.

If you don't think about the features you add to your applications they won't fit in. If there's some off shoot piece of functionality that doesn't make sense with the rest of the application, not only will no one use it, but it gets in the way of the features they do like. At the very least, that new menu item for the new feature is going to mess up the muscle memory the users have built up to pick the good feature out of the menu. Maybe you introduced some new bugs in the good features while implementing the bad ones. Maybe the usage of the popular feature completely changed because of extra steps needed to distinguish it or its process from the useless feature. I'd be willing to bet that your application is also a lot more difficult to maintain than if the new feature just used all of the conventions and frameworks you already had in place.

And that's what I see happening around here as deadlines draw near. We are not taking the time to design usable, powerful and simple features that give customers real solutions to their problems and integrate wonderfully with the rest of the application. We seem to be taking their ideas and implementing them exactly as the are asked for instead of maintaining the consistency and integrity of the application. Hell, how many times does a customer ask for a change that really solves their problem anyway? This is not organic growth; this is Franken-cancer. It is not going to take long before one customer's request or sales-person's demand interferes directly with another. This causes the application to have many more preferences and settings that need to be set just to use the darned thing. We're going to spend more and more time cleaning the cruft and bugs out. And, no one will use any of those half designed features anyway because even though they asked to be able to pick corn off their spider plants, what they really needed were catered lunches.

Monday, September 10, 2007

The Mythical Man-Month: Why I Like Specs

So I've been reading a lot about project management and better ways to architect applications lately; design, process, code organization and interaction, and the like. One of the classic books out there that every one should read is "The Mythical Man-Month".

I'm sure we're all familiar with the little gem "nine women cannot have a baby in one month." But TM3 goes on to explain why creating a software application is more like creating a baby and less like building a bridge, at least as far as the additional woman-power goes. People are not interchangeable; visions are inconsistent, misunderstood, or incompatible; ramp up time must be accounted for; etc.


The book explains some ways that software design and implementation can be scaled up to teams of a thousand if need be without conflict of vision getting in the way. There are many processes and responsibilities that each person on a team has that allows them to work together without that conflict becoming a problem. Of particular immediate interest to me is the need for written specifications. "Why would you write about the importance of written specs? Everyone knows you need them, don't they?" Right.


"The manual is the external specification of the product. It describes and prescribes every detail of what the user sees... The manual must not only describe everything the user does see, including all interfaces; it must also refrain from describing what the user does not see."

All I can say from personal experience is that not following this wisdom causes problems. It is hard enough for one individual to have a vision of what your product should be. If that vision is not documented, it can not be implemented truly. If the visionary attempts to implement all of the vision on paper, as mock-ups or in code, there will never be enough time to complete the implementation. Divide the responsibilities and communicate.

Addendum 9/13/2007:

After reading a bit more of the book I have found that there are some chapters that are truly outdated. I would still recommend reading the book however. It is fairly easy to identify the sections that are aging; they usually contain a reference to OS 360 or some other decades old system. Still, it is a useful exercise to contemplate those sections to see how they apply to the present day.

Most of the concepts presented are still relevant. The examples are not necessarily as meaningful as they once were and the solutions presented are usually either outdated or never came into wide acceptance in the first place, so it is interesting to draw parallels to the solutions that exist today or to dream up a solution if one was never found.

There are a couple of chapters that just don't seem relevant to the general programming population of today though. The chapter on size limitation seems particularly quaint. While there may be some situations where developers of embedded devices still need to constrain the overall size of their software, I doubt any OS, web or intranet developer has been seriously constrained by byte limitations anytime recently. Not that we don't try to write code as concisely as possible, but legibility and maintainability are usually the primary goals.

Still a great book to read.