Tonight I found out that it's actually possible to discover, to your dismay, that things are even more like what you thought they were than you thought they were. And so the same solution is, of course, that much more necessary.
Montreal free museums day is Sunday, May 28. I have marked it in my calendar. Have you?
I currently live in a miniature domed city with artificially increased oxygen content and humidity, tropical plants, and lots and lots of fountains and waterfalls. I like it.
The "bad" news is it's unlikely I'll actually see the outside of this little ecosphere (ie. the rest of Nashville) before it's time to go home. That means my opinion of Nashville will be 100% pure bias. But it does seem nice.
Today, my life is truly complete, for I have witnessed a pile of 30 stuffed Nitix bunnies, all about 10 times cuter (and cuddlier) than I ever imagined. I don't care anymore if this marketing gimmick works. I want them all. And I don't even really like stuffed animals.
Note to self: bring your camera next time you go to a conference, idiot.
You know you're doing something right when actual respectable people start wanting to deal with you. Today I helped an obviously really, really good technical trainer tune his 3.5 hour presentation (which people are paying to go see) about our product. And he asked some really good questions.
I remember a few years ago when I first saw the "SalesDance" video of people actually selling all this stuff me and dcoombs had made up, like Tunnel Vision and Double Vision and idb. It weirded me out, thinking I had screwed up, err, improved the lives of so many people. This is the same feeling again, because it's really a new phase: people we're not even paying are spreading this stuff around. And that means they really mean it.
It's an honour, really. It feels weird.
The Bunny Exponential
As we distributed the bunnies, it was very interesting watching us cross The Tipping Point as awareness of us (well, at least our tradeshow booth, and maybe our product) began to rise exponentially.
Also, all sexism aside, the bunny promotion would have been quite ineffective if there weren't a much higher percentage of women in the accounting software business than in normal IT. It was very obvious which gender was and was not bunny-focused. Not that this should be very surprising, I suppose, but it's interesting to note since women are of course badly under-targeted in technology marketing. That's probably a major reason why the gimmick was successful.
Gratuitous Misuse of Technology
Except in the US (where there is a person named Mr. Meese), Google Trends says mooses are more common than meese. This is of course very disappointing to me. In an incidental but Linux-related note, Finland is by far the most opinionated on the topic, with almost no searches for "meese" compared to "mooses."
People have told me that the only way to win at negotiating is to "be willing to walk away."
So what happens if you've aligned everything perfectly to make your point logically unassailable, and you are willing to walk away? Perhaps you then realize: if you were really willing to walk away, then you didn't care about the outcome anyway.
If that's what it takes to win, then you have a pretty funny definition of winning.
That kind of negotiation is a "win-lose" negotiation: if you're trying to negotiate in a non-compromise way, then there is no "loser" from an exchange. There is only the "right" answer that makes both parties better off.
I think the best negotiations are the ones where everyone cares too much too walk away. That way everyone wins.
But if you're going to believe that, then beware the sort of person who is willing to walk away. They exist, and they'll eat you for lunch. And they won't even care.
Zen, Betty Crocker, and End-to-End Testing
I don't know if this story is true or not, but I heard it somewhere and it makes a point, so here we go.
A maker of cake mixes was investigating two cake mix designs. One, their traditional recipe, included powdered egg in the mix, and a new one required the end users to add their own eggs. Chemically, the result was about the same, but a competitor's "add your own eggs" mix was starting to gain market share over their existing all-in-one product. They decided to do some market research to find out why.
They conducted a taste test in a statistically valid fashion, with double blinds, etc. Presented with two cakes side by side, tasters on average had no particular preference for one mix or the other; they tasted the same.
This was very nice, but didn't explain the problem: why would the new market entrant be getting so popular, then? They had less advertising, no name brand, and you had to add your own eggs!
They had an idea and decided to run another test: this time, the tasters had to also bake the cake themselves, and they obviously knew which cake was made from which recipe (but were hidden from the brand name, packaging, etc). In this test, the tasters clearly preferred the cake where they had to add their own eggs.
They had more of an emotional investment in the egg-added cake; it contained "fresh ingredients" that they had to buy and add themselves. It took a tiny bit more work. They didn't feel like they were cheating as much when they made a mix that didn't have all the ingredients built in.
Ironically, we tend to believe that people buy cake mixes to save time and effort (ie. they're lazy); this makes the "add eggs" mix seem inferior. But what the researchers discovered was that people buy cake mixes not just to save time, but because they don't feel competent to add all the ingredients themselves (ie. they're scared). Making the end user do slightly more work makes them feel more productive and gives them more emotional involvement in the end product, without scaring them away with complexity. That's the first lesson.
The second lesson is about unit testing; the cake mix engineers were looking in the product specifications for why it wasn't selling, and constructed a perfect unit test to identify and help correct their assumed problem (if the eggs-included recipe had measured worse, they could have improved the recipe). But the test, while scientifically and statistically valid, included some hidden assumptions that also needed to be tested: that taste affects the desirability of the product; that less end-user effort is an improvement. The proper test to find the problem was closer to an "end-to-end" test: it included much more of the "cake mix consumption" process in the test, not just the part where you eat the cake.
And the third lesson is about the Zen of cake mixes and how capitalism has helped us get closer to it. Years ago, under adult supervision, I remember using cake mixes that didn't require you to add your own eggs; they were just fine. But how many mixes can you find nowadays that don't require eggs?
Traits and Roles
The distinction between "traits" and "roles" seems to be a popular topic in object-oriented design lately. Once you think about it, the distinction is obvious, but when you mix up the two, your programs are crap.
Being the Perl god is a role. Being a stubborn cuss is a trait. :-)
-- Larry Wall
The same distinction applies to designing companies as well. People are defined by their traits; what they do are their roles. I've been terrified in the last few days by the confusion between these two concepts: people who actually believe that your role defines who you are.
"You're in marketing now, why should I listen to you about how to design this?" WHAT?? After four years of working with you as an architect, it turns out that my architecture skills depend on my job description?
A sledgehammer is big and powerful. Someone with excellent sledgehammer skills can use that sledgehammer to great effect. But if the role is swatting flies, the sledgehammer is just not going to work. Meanwhile, even an idiot can use a flyswatter to swat flies.
Traits aren't the same as roles. Your traits very much determine your effectiveness at a role. But yeesh, changing your role doesn't change your traits! How could it?
Architecture is Strategy
And so I bring you: the architecture is the strategy.
At the risk of explaining myself and therefore seeming less wise and inscrutable, what I mean is: the strategy of a company is its long-term goals. With every little short-term decision, you need to be thinking of how it will move you one step toward your long-term goal. Most short-term decisions that seem beneficial won't get you where you want to go; they'll just keep you alive. The magic of a good strategy is that it takes not much more work in the short term, but you actually get somewhere in the long term.
It's the same with software architecture. Sometimes you make a decision to implement something one way instead of another because you know that you're going to be better off in the long term. "Sure, I could just use global variables for everything and would save me some time today. But none of my functions would be reusable later." But what if you have no long-term plan? If you're a consultant, for example, developing precisely whatever someone pays you develop on each contract, there's no pattern to the work, and your short term gain is your only gain. This can be profitable, but you'll never get anywhere but where you already are.
Some people refuse to think beyond the scope of their current project; some people, even beyond the scope of the current phase of their current project. Those people don't understand strategy and don't want to; they'll work for someone else's strategy, if you pay them, because they don't particularly care where they end up in the long term. People like that make good workers, but terrible architects. Because if you don't understand the strategy, you don't understand how the work you do today is torpedoing the work you'll need to do tomorrow.
This also explains why business non-strategists don't see the value of software architects. It doesn't fit into their world view. If we can do our work today, and we don't know what's coming tomorrow, what good could a different architecture do?