Christopher Hawkins - effective Software Development and Web Design project management

Tuesday, January 24, 2006

Of Dogfood and Soda Police

I encountered an interesting news article today. It seems that one Ford plant has decided to force employees to drive a Ford or be barred from the plant's parking lot rather than being allowed to park in the facility's parking lot.

In the software industry, the phrase "eating your own dogfood" means that you actually use the products you develop. In general, this is a good thing; it leads to higher levels of quality and a deeper understanding of the user experience. But I think Ford is taking it much, much too far. We're not talking about using Ford products at work for the sake of understanding the user experience; we're now talking about Ford penalizing employees for what they purchase with their personal money, on personal time. That's nuts.

I am reminded of a story I was recently told by an acquaintance about the HR department at his work. The HR staffers would actually search the refrigerator and employee's lunches to make sure nobody had brought in any Mountain Dew from home. Why? Because the company had struck a deal with a Mountain Dew vendor to provide vending service to their office building at reduced cost on the condition that anyone who consumed Mountain Dew in the building would ONLY consume Mountain Dew that came from the actual Mountain Dew machines. So, the Soda Police from HR would check cubicles and lunch bags and refrigerators in search of illicit soda. We've all heard stories about Furniture Police and Cubicle Police in the corporate world; now we have Soda Police. Just saying the term "illicit soda" out loud makes me doubt humanity's odds of long-term survival.

Anyway. Back to the Ford issue. The Soda Police episode makes me wonder; what if someone who works at that Ford plant comes to work in an old Ford that has, say, a non-Ford engine in it? Are the Ford Police at the plant going to check under the hood to make sure that each employee's vehicle is 100% Ford? Suppose it's a 1940s-era Ford truck that has been restored and is composed mostly of non-Ford aftermarket parts? Is it still a Ford? What if it's a 1988 Ford Escort, but has had all the badges removed, or has had extensive body modifications so that it is not visually identifiable as a Ford? Is it still a Ford if it doesn't actually look like a Ford, or SAY Ford on it?

Isn't this just a little bit like Microsoft or Intuit announcing that all employees MUST use Word or Quicken (respectively) at home, and that any employee caught NOT using Word or Quicken will not be allowed to eat lunch in the company cafeteria? I understand the desire to have brand loyalty, I understand the desire to show a consolidated face to the competition, I understand the desire for eating your own dogfood in the hopes that it leads to a better customer experience. But wouldn't a better alternative be to allocate a loaner car or two for the plant and have employees trade off driving it? Even better, give each employee one day per month to get out of the plant and run errands while driving a Ford. They could get a feel for the product they build on a daily basis, and perhaps come to have new ideas about how to make it better. Heck, some of them might even fall in love with it and decide to buy a Ford. Mandating that employees must either drive a Ford or park off-site seems as though it's going to do nothing but create resentment.

If the management who put this policy in place were smarter, they'd be asking the REAL question - why aren't all of our employees willingly driving Fords already? I suspect that the reason they haven't asked that question is that they already know the answer, and they don't like it.

I realize this is not, strictly speaking, a software business topic. However, it IS a "stupid management" topic, which happens to be the #1 problem we face in the software business.

02:41 PM

What's The Point of CSS-Based Layout Again?

Can someone remind me again why moving away from table-based layout in favor of CSS layout is important?

This isn't a bashing post; I "get" how handy CSS is and I get that the whole world of the web is eventually going to all-CSS. I get that all-CSS sites use less bandwidth. I get it, I really do. Perhaps I'm ranting because I've had a very frustrating CSS morning.

But that doesn't change the fact that even after working with CSS-based layout for a solid year now, I can STILL turn out a table-based design that does exactly what I want it to do faster than I can turn out a CSS design that does the same. It also doesn't change the fact that every important site I use on a regular basis is table-based. Amazon. CNN. Microsoft. Inc. Forbes. Even Google! It seems that the vast majority of the web is table-based, and the vast majority of the web appears to render just fine in either FF or IE.

So as I bust my hump learning a whole new way of doing things, I have to wonder; if table-based layout is good enough for those huge players I just named, why isn't it good enough for the rest of us?

I will continue to work with all-CSS layouts, but I have the distinct feeling that I'm doing it more because that's what everyone else is doing then because there are compelling benefits to doing so. And I don't like that feeling.

01:28 PM

About Christopher

I am the founder and principal developer of Cogeian Systems, specializing in custom software development, web design/development, and crisis management for software projects.

In May of 2012 I also founded SmallSpec, a web app that enables freelancers and small teams to create painless functional specifications.

Everything you see in this blog is my own personal opinion, based on my experience in the software field.

Follow Christopher on Twitter

©Copyright 2004 Christopher Hawkins | web design: Cogeian Systems