Yesterday I read a short white paper about some experiences with developing open source software for the Department of Defense (DoD.) It was a good read and relevant considering that we (Gestalt) have been pushing more and more of our software for the DoD coming out of the Joplin, MO office to the open source community. One of the points made in the paper was that successful open source projects need a benevolent dictator. I’ve always believed this to be true, but then I read Josh Berkus’ post on The Myth of The Benevolent Dictator and am not so sure now.
Josh Berkus is a lead developer for PostgreSQL. While MySQL often gets the glory, PostgreSQL has quietly earned respect by hardcore database people. I’m one of those people who has a lot of respect for the PostgreSQL project as a whole, so when one of the lead developers expresses a strong opinion I’m prone to listen. (Plus, the guy has one of the best first names ever.) Josh’s main point is that it’s too easy to say that successful open source projects need to have a benevolent dictator. There are all sorts of models that have succeeded. PostgreSQL is a democracy. Debian is a chaotic democracy. Apache is a bureaucracy. MySQL is a company. Java is a mixed bag of everything. But, it’s more fun to look to the benevolent dictator for quotes and it’s more convenient to sum up the success of open source project leadership in two words.
There has to be clear leadership for any software project, open source or not. I think the important thing to keep in mind is that open source software has been successful with various models of project leadership. The benevolent dictator is one model that has worked for Linux and others, but it is only one of many.
I realize this conclusion will likely disappoint one of my Gestalt comrades who sometimes fancies himself a benevolent dictator, but it had to happen sooner or later. At least he’ll always have “The Lovinator”, which is something that is ALL his and likely always will be. Dictate away!
Looks like Seth Godin has noticed the same stellar service at Home Depot that I have of late. Mind you, I’m not hanging out at Home Depot much, but the last few visits have been filled with frustration. Aisles are a mess, shelves are even worse, and the checkout clerks take “it’s not my problem” to a whole new level.
The best is when my Dad and I were ready to pay for a few items at the local Home Depot here in Joplin, MO. I suggested we go through the self-checkout. My last experience at this Home Depot told me that the counter intuitive self-checkout machines were a safer bet. My Dad spotted a clerk with an open lane so it was too late. He approached the register and asked the clerk how he was doing. The guy replied with, “I’m pretty pissed off right now,” raises his voice, “See that girl right over there at that register? She’s telling me what to do. She’s only worked here one week and she thinks she knows everything.” Uh-huh, OK. Thanks for sharing buddy.
Following up on my initial post on the book, Made to Stick, I wanted to touch on the second of the six major factors that contribute to making an idea sticky – unexpectedness. Before I do that, I’ll list all six factors here:
Unexpectedness is sometimes equated with shock value. I would argue that urban legends like the one Made to Stick starts off with provide a certain amount of shock value that makes the unexpected all the more memorable, but shock value is not necessary to achieve unexpectedness. If shock value was a requirement for sticky ideas, then most of us would be out of luck.
A great example of unexpectedness in the book comes from Nordstrom. Like many companies, one of Nordstrom’s core values is great customer service. Snooze, right? But, then follow up that core value with anecdotes like this:
- A refund is given to a customer returning tires even though Nordstrom doesn’t sell tires
- Items purchased at another store are gift wrapped by a Norstrom’s sales person
- A Norstrom’s salesperson warms up a car for a customer on a cold winter day
Imagine going through Nordstrom’s orientation as “just another salesperson”, hear the spiel on “customer service is #1” and then be surprised by the examples above. The idea of “great customer service” just took on a fresh new meaning due to the unexpectedness of the examples.
After reading the book I thought about former North Carolina men’s basketball coach Dean Smith and his simple motto of “play hard, together, and smart.” Wow, thanks coach. Next you’re going to tell us to give it 110% and remind us there is no “i” in team. But wait, Dean Smith backed up his simple message with unexpected behavior. Most assume that a coach is going to be happy with a win and upset with a loss. Not so with Dean Smith. He didn’t like losing, but if his team played hard, together, and smart, but came away with a loss, he praised them. If the team didn’t play hard, together, and smart, coach Smith would not be pleased with his team’s performance.
Both the examples of Nordstrom and Dean Smith show that unexpectedness is not necessarily driven by extraordinary events or stories, which I find quite encouraging. Now I just need to master the concept in real life!
A link to this post should show up at http://twitter.com/joshuahoover
Blasphemy, I know. You might be thinking that I meant to title this post, “.NET Sucks!”, right? Sorry to disappoint my Java loving co-workers. Of course, I’m not speaking about .NET, but the excellent podcast by the name of .NET Rocks! I have yet to find another developer focused podcast so informative and entertaining. The amazing thing about .NET Rocks! to me is that it spends quite a bit of time covering topics like Open Source software and agile software development that some would consider anti-Microsoft. It gets even better when Richard Campbell and Carl Franklin discuss topics like SOA (and what it’s really about), Enterprise Architecture, Version Control and CI, or being “Code Complete” with Steve McConnell. Each of those individual episodes I reference are highly recommended listens, especially the SOA and Enterprise Architecture ones.
“We found out we got a whole lot less done when we’re sitting next to each other the whole time.” -Jason Fried, 37 Signals
That quote comes from a short interview Jason Fried did with Crain’s Chicago Business. That point of view collides with those like me who promote co-located teams as a way to increase productivity. Co-located teams are often a core value of agile software development. But, want to know a little secret? I think there’s a lot of truth in what Jason says.
I think co-located too often translates to distractions galore. Software developers need to get into “the flow”. When they’re in the flow, developers are at their most productive. Everything starts to click and the results are often astonishing. You can’t get into the flow when you’re dealing with distractions and interruptions. Interruptions don’t have to be direct, like a team member asking you a spontaneous question, they can be the result of an open space environment where every conversation is overheard and tempts you to join in.
There are times when being co-located pays off in some big ways. For instance, when you have multiple developers working on solving a problem together or when someone overhears a conversation, jumps in and a seemingly difficult problem suddenly becomes easy to solve thanks to the contributions from someone not originally involved. However, I often wonder if these instances are the exceptions rather than the rules.
Maybe the balance is to be in the same vicinity but not co-located in an open space where distractions are so plentiful? Co-locating can be reserved for those times when it’s needed by always having available open meeting spaces for such occasions. Possibly utilizing IM and chat rooms for a less obtrusive form of collaborating while not co-located. When people feel that it’s important to meet together, then they easily can. Co-location in this setup becomes the exception rather than the rule. Is it possible to get the best of both worlds?
I’m not hip. I don’t get Facebook. I understand the concept but I don’t get the hype around it. OK, it’s a platform. But, maybe I’m missing something. The whole point of the Facebook platform seems to be about locking you into Facebook. Another well hyped web app is Twitter. While I don’t use Twitter (nor the numerous competitors), I think I get it. Twitter’s API makes more sense to me. Twitter isn’t locking you into a platform like Facebook is. Am I over simplifying things?
You’d think Amazon would try to build out a platform of sorts with their AWS offerings. Who knows, maybe they are. But, I think Amazon is taking more of the approach I see in services like Twitter — providing well focused services like the Flexible Payments Service (FPS) and Simple Queue Service (SQS) rather than an all encompassing platform that makes the seemingly limitless Internet and web rather limited.
So, what is it that I don’t get about Facebook that many others do?
Have you ever had to sell people on an idea? Ever needed to get people to focus on a common goal? I know I do, even though the ideas and goals normally aren’t earth shattering. Made to Stick, as the cover says, explains “why some ideas survive and others die.”
The authors, Chip and Dan Heath, give six major factors that typically determine whether an idea will survive or not. The first, and most important factor, is keeping things simple. Duh. That was my first thought as I started reading the chapter. Then the examples started coming. Southwest’s core value of being “THE low fare airline.” It almost sounds too simple. Then an example of how this simple, yet core idea at Southwest translates to the day-to-day:
“Tracy from marketing comes into your office. She says her surveys indicate that the passengers might enjoy a light entree on the Houston to Las Vegas flight. All we offer is peanuts and she thinks a nice chicken Caesar salad would be popular. What do you say? . . .
You say, ‘Tracy, will adding that chicken caesar salad make us THE low-fare airline from Houston to Las Vegas? Because if it doesn’t help us become the unchallenged low-fare airline, we’re not serving any damn chicken salad.'”
The key with keeping ideas simple isn’t to dumb them down, rather it’s all about capturing the core idea. An example is when Bill Clinton ran for President in 1992. The former President’s campaign ran on the now famous mantra of “It’s the economy, stupid.” While Clinton was constantly tempted to get into endless policy debates, James Carville reminded him that winning the election hinged on sticking to the core idea of “It’s the economy, stupid.” Regardless of your politics, Clinton’s ’92 campaign was genius and to think it all revolved around four little words.
I believe that much frustration comes from people not being able to communicate their ideas in a way that people remember and latch onto. I know that I’m far too often left scratching my head wondering why a person or group of people didn’t buy into what I was telling them. Now I think I have a better understanding and intend to put to practice the principles taught in Made to Stick.
I’ll write about the other five factors that make ideas sticky in future posts. There’s too much good stuff to capture in one post.
P.S. Not only is Made to Stick a great book, but it comes with a great cover. Everyone who sees it immediately goes to touch the duct tape part of the cover. Very clever.
There have been a lot of good posts about SOA lately. Gestalt’s CTO, Jim Stogdill, points to both an article by Cynthia Rettig and Nicholas Carr’s follow up on Rettig’s article. The take away from these articles and posts seems to be that just as ERP software implementations have been plagued with mind numbing complexity, SOA is likely only adding another layer of complexity (or more!) on top of a fragile foundation.
Nick Malick, a Microsoft Enterprise Architect, also has some interesting thoughts on how we in the IT biz sell SOA to our customers. Nick has this to say regarding selling SOA to customers:
We do talk about SOA, just not with the business. It’s not that the business doesn’t understand SOA, or wouldn’t if we told them… it’s just that they are not incented to care. If I walk into a business meeting with the head of the Volume Licensing organization, I have to realize that his operational team books a little over $1B in revenue to Microsoft’s bottom line every month. Let’s say I take an hour of his time. During that hour, his organization has closed on $6M in revenue. If I ask for $200,000 for SOA, when SOA is basically good design done well, using modern tools, many of them free… I’ve wasted his time.
Well said Nick! While it’s easy to pile on SOA, I think all things “agile” and “lean” in the IT world need to be put under the same scrutiny. When a buzzword becomes the focus of the conversation with customers, be weary. Just as we in the IT biz often throw around SOA as the solution to just about any problem we come across, I’m finding that the terms “agile” and “lean” are treated in much the same way. I cringe when I hear about organizations that believe they’ve turned the titanic 180 degrees almost on a dime since they adopted agile/lean processes and best practices. It’s as if reality goes out the window and the buzzwords act as some sort of mind altering drug that makes things magically better.
How do we prevent the hysteria that inevitably arrives around new technologies and software development processes? I can think of some but they’re never as easy as saying a buzzword or two. For instance, we need to focus on the problems that we’re trying to solve, not the other way around. Who knows, maybe the problems require much more than SOA, agile, lean, etc. can solve. I think once we focus on the problem first and solutions second we then need to be more specific when we talk about these buzzword solutions. SOA, agile, lean, etc. likely mean one thing to me and quite another to you. By being more specific in what we’re really talking about we combat the one word answers that only build the buzz.
I was sceptical that VirtualBox, an open source desktop virtualization software package, could be a viable alternative to VMWare and Parallels. I’m happy to report that my early experiences with it have been fantastic. The biggest issue I had was with my Microsoft Vista Home Premium guest OS (i.e. an OS running inside of VirtualBox) not having a driver out-of-the-box for the network adapter VirtualBox and most of the other virtualization solutions use. Oh the irony. Windows has the driver problems, not Linux this time around. Ha!
I documented my issue and solution to the network driver problem on the VirtualBox issue tracker site. In order to get the word out just a bit more through the search engines, I’m posting my problem and solution here.
- Fresh Kubuntu 7.04 install on a Gateway MT6840 notebook (Centrino Duo platform)
- VirtualBox 1.4 install from the VirtualBox debian repository
- VirtualBox “Guest Additions” installed
- Network connection through my wireless card only on eth1
- Guest OS on VirtualBox is Vista Home Premium (I know, I know…licensing issues…sigh)
Everything went fine until I tried to get networking on Vista working. I learned quickly that there are issues with Vista not supporting (out-of-the-box) the network card VirtualBox emulates (AMD PCnet Ethernet card.) The answer to this is to install the “Guest Additions”, go through the Windows “New Hardware Wizard” and point it to the CD drive, which should be an ISO image of drivers from the “Guest Addition” installer. However, when I followed this process Vista would go to install the driver and then freeze about 10 seconds into the install. The only thing I could do then was do a hard reset from the VirtualBox “File” menu. After trying numerous potential workarounds, I stumbled upon the solution:
- Go to VirtualBox and select the “Network” link under the “Details” tab for your Vista VM image
- In the Network Details tab select the appropriate network adapter (eth1 in my case) and then make sure you have these settings:
- Check “Enable Network Adapter”
- Select “Not attached” for the “Attached to” menu
- Check OFF the “Connected” checkbox
- Click OK to save the changes
- Start up Vista
- After you login, go to the VirtualBox “Devices” menu and select “Mount CD/DVD-ROM”->”CD/DVD-ROM Image”
- Select “VBoxAdditions.iso” and click “Select”
- From the “Start menu” right-click on “Computer” and select “Manage”
- Click on “Device Manager” to see all the devices
- Right click on your computer’s name in the “Device Manager” and select “Scan for hardware changes”
- You should be prompted to install a driver for your network controller
- When prompted, tell Windows to look for the driver on your CD driver under the “AMD_PCnet” directory on the drive
- Vista should successfully install the driver
- Shutdown Vista from the “Start Menu”
- Perform steps 1 & 2 (different sub-steps for 2 are below)
- Check “Enable Ethernet Adapter”
- Select “NAT” for the “Attached to” menu
- Check ON the “Connected” checkbox
- Click OK to save the changes
- Start up Vista and you should now have network connectivity
If you’ve had this problem with Vista as a guest OS using VirtualBox and these steps helped or didn’t help, please feel free to leave a comment.