Bonuses considered harmful

Did I nod off or something? The meeting had started out well enough, a mind-numbing Powerpoint talking about the methodically developed rewards structure and how there were professionals with years of experience deploying this very bonus structure to Fortune Yadda Yadda companies but the presentation over, people started asking questions, and that's where things started going hella bad.
The company I work for started out its life as a start-up and was eventually bought out by a much larger company. When the corporation's new management came in, they gave us the feel-good bill of goods: you're the best of the best, entrepreneurial spirit, turn on a dime, yadda yadda.
But the honeymoon had to end sooner or later and this wasn't getting pretty, for one big reason - people had counted on the fact that we were, after all, the best of the best, and this naturally meant that when it came time for the annual bonuses and raises, they were going to make bank. Except now, the ugly reality was setting in - deadlines we had no say in defining had been blown and there had to be repercussions. Oh, and you're already being paid over market value, so don't hold your breath on that raise either.
Nobody's buying it. The mood's getting palpably hostile.
Reiteration. This works for big companies and my hands are tied.
Some people resigned themselves to reality, others just... resigned.

So I've seen what can go wrong when you dangle the carrot in front of people. But for myself, I just don't care about the carrot. I was excited when I got a big raise a few years back, but I've been given bonuses multiple times since and have been completely unenthused by them.
I must be an insane person, right? I live in a capatalist/consumerist society; I should love money and being given more of it should make me excited, right?
After all, when you get down to it, I'm just a developer. I took a couple of management classes in college (I promptly forgot everything except for the goofy terminology like ROI and core competency and other bits and pieces I sprinkle liberally when I'm being a dick) so what do I know about bonuses? Very smart people came up with the bonus structure and everyone understands the stick and the carrot so I must be an aberration.
Except for the fact that, thank god, I'm not the only person that thinks this way. Alfie Kohn's written books challenging conventional wisdom on bonuses and strict management structure, and there's a few of his papers up on his internets site.
Go read his papers and you'll find the same theme repeating itself - bonuses (or, in way-smarter-than-me parlance, "extrinsic inducements") have been proven time and time again to fail to work. At best, you get an initial boost, but given a little time, the problems that bonuses create (making co-workers adversaries rather than, well, co-workers by breeding feelings of resentment to name one) quickly outweigh any of the quick-fix wins that you may have realized from them.

That rewards can't get us what we want is a heretical idea, but it emerges ineluctably from a critical analysis of motivation and work.
- Alfie Kohn, Challenging Behaviorist Dogma

About two dozen studies from the field of social psychology conclusively show that people who expect to receive a reward do not perform as well as those who expect nothing. This result, which holds for all sorts of rewards, people and tasks, is most dramatic when creativity is involved.
- Alfie Kohn, For Best Results, Forget the Bonus

Still not buying it? Let me try the metaphor that came to me when I was out cycling.
Why was I so much happier to get a cheap-o t-shirt with some of the in-jokey slogans celebrating the release of our product than I was to get thousands of dollars of bonuses?
Growing up, I had two hypothetical Aunts, Annie and Betty. Every year for my birthday, Aunt Annie gave me a little toy. Every year, Aunt Betty gave me a crisp twenty dollar bill.
Whose present would you look forward to and appreciate more - the one that shows that she's spent time figuring out what a kid your age would want or the one that shows that she's got a wallet and maybe an iron?

The case for McMansion architects (part 2)

So I think I might even have reasonably established that handing off a specification to an architect (no matter how good) is necessarily going to be nothing but an unmitigated disaster if you're expecting something arable the first go-round.
But these McMansions, these big, generic, samey houses. These enterprise software applications, this big, onerous, pay a million and pay a million more for consultants to get something nominally useful that no one likes using programs. Why do they get built in the first place?
I keep coming back to a PBS Frontline program called The Persuaders and in particular, the interview with Clotaire Rapaille, a French cat who isn't afraid to pose like he's in a rap video in front of his mansion with his cars (seriously, check the picture on the front page of his internets site) and proffer a bastardization of Jungian archetypes and Lacanian linguistic dynamics for mad profit.
As he explains in the program, the car companies came to him, looking to get in touch with their consumers and give them something that would jump off the lots, so he started interviewing people and came to a revelation - bigger automobiles, taller off the ground, with tinted windows were "code" for "wealth", "power" and "domination."
Rapaille talks about drilling through the mammal brain and speaking directly to the lizard brain. John Coltrane put it more eloquently - "The emotional reaction is all that matters. As long as there is some feeling of communication, it isn't necessary that it be understood." Rapaille sure was on to something with making them SUVs bigger and taller and whatnot, because they provoke gut responses in people. You ask people who drive them why they drive them and they'll tell you "because I feel safer in them" and it really doesn't matter if you were to put the crash tests that say otherwise in front of them. They're safer and that's all there is to it. You ask me, who would just as soon drive a goofy European-small car, about them and I hate them because they're gaudy monuments of conspicuous consumption.
But underneath my upturned nose, I'll admit it - there's the seeds of jealousy in there. I can't explain why, either. I've driven them and hate driving them. I don't like being up high, they handle like tanks and jesus christ the gas milage. But still, when I'm driving behind some jackhole and I can't see through the blacked-out rear window to the car in front of them, wouldn't it be nice to be able to see the guy in front of them?
Why the McMansions? In this context, I think it's easy to see where the infatuation with more house and less soul than you need comes from. For the same money you're putting out on a McMansion (and probably more because deviation from the crowd is gonna cost you), you're ultimately getting "less" house. There's safety in numbers and everyone else is doing it, so it takes an extra dose of courage to get it done.
You can't define soul, but square footage is easy to quantify.
Think about it - deep down inside, you've got that sense of unease gnawing at your stomach. You're spending more money for ultimately less house. The garish abomination that they're building is more than they need, isn't built for them but rather some generic approximization of them, they can't afford it, but... they're getting a whole lot of square footage and maybe I could make it my own by decorating it nicely and choosing the fixtures I'll have the place built out with? It's easy to slide back to the road more travelled.
The lowest common denominator is hard to argue with for a reason. IBM may not be the greatest, but nobody ever got fired for buying it. Budweiser and McDonald's suck, but won't you come off like a snob if you tell your friends you want to get something better?
I'd like to think that I have the courage to admit to myself and others that I'm OK with smaller and better. You probably have the same courage... but do we have the courage?
Product development comes up with a giant specification. You may have the courage to question whether a service-oriented n-tier architecture implemented in .Net 2.0 and redundant Oracle databases communicating with your Oracle Financials OLTP system with the data cached in XML for quick retrieval and the requisite smattering of patterns talk makes any sense whatsoever for this hypothetical product, but how convincing of an argument can you make to the contrary
Product development probably isn't really interested in hearing that these dozens of features that they've spent weeks and months painstakingly realizing and documenting probably aren't needed. Management isn't going to be sold on you telling them that less being more - they see their career riding on hundreds of pages worth of specification and who is this programmer to tell me that less is more and we don't need these features that product development does? We paid that architect good money for a good reason.
McMansions, SUVs and enterprise class software are all about us being sold what we want instead of what we need. It awfully hard to argue with the inner child that's having problems rationalizing away the fact that we're paying 15 percent more money for 15 percent less square footage. Peopleware costs a boatload and wow look at all of the things that it can do (I've tried to figure out what it is and near as I can figure, they've managed to assemble what I can only describe as a Rorschach application), so it can obviously do what we want (nevermind that we need to use the thing and that may not be possible). It's hard enough to argue with our inner child; you get a room full of inner children together and the odds of common sense rearing its pretty head rapidly approach zero.
A quote I've heard that's apt - "in a community of saints, we are all sinners."

The case for McMansion architects (part 1)

So I'm reading an interesting piece decrying "McMansion" software architecture and totally nodding my head. Raganwald's a better writer and smarter than I am (PLEASE DON'T HATE ME MR. WALD) and given that a recurring theme in his posts is casting "best practices" aside and being brutally intellectually honest about what you're doing and how it's failing and can be ameliorated, he's right. But as the devil's advocate with a massive failure of vision, here I go sticking my foot in my mouth.
It's an interesting article to be sure, but at the end of the day, it feels like it's restating Brooks' thesis on essential and accidental difficulties in software development (yes I just reread The Mythical Man-Month, what of it?).
There's a part of me that's totally nodding in agreement at being saddled with cookie-cutter
concepts and then there's another part of me that's scratching my head about what exactly is wrong with using databases and XML and all the other unsexy (proven) technologies that the anonymous architect has proposed to bring the app from a "telephone book sized specification" of requirements to an implemented product. There's a part of me that's giving an e-high five for sticking it to consultants who are paid too much to use a metric ton of buzzwords to not quite tell you what you already know and a part of me that's wondering what exactly is wrong with using COTS products and technologies since I'm not a world-class developer and don't work with world-class hackers and maybe I won't see as many exciting things on the road more travelled, but I won't fall off a cliff either.
I honestly feel bad for the architect. Think about it for a second - a specification that probably runs upwards of a hundred pages. I haven't seen the spec or the proposal, but I feel safe in asking the question - who could possibly put together a proposal that would sanely satisfy something like that? If I'm Raganwald, I'm probably going to outwardly scoff to anyone unfortunate enough to listen to me because I'm an asshole like that, but at the same time I've got to be happy that there's progress that's been made. OK, the initial draft sucks and the architect looks like a chump and here's a dozen reasons why, but at least we're moving from something proposed by a group of people (I doubt it was one person who was put together that specification; I'm assuming that it was spec'd by a committee and written by a couple of people) into a proposal that I can digest and critique and iteratively improve upon to a point where we have a good enough idea of what we're all talking about that we can actually make something.
The initial architecture proposal sucks? I'd be astonished if it didn't. Using XML is the wrong decision? Thank god we're far enough along that I can definitively say that. That's better than we were a telephone book ago.
Above and beyond the obvious problem (a mammoth spec), in handing it to an outside entity, you're dealing with some unspoken problems. That specification is ostensibly the crystallized desires of a group of people, but hiding deep beneath and in-between the lines are the unspoken desires of people that never made it in there. How much of what ended up on the cutting floor could be picked up and stitched together into a fabric that details the essence of what they're after? Was the spec handed off to a single person to trim the fat off of everything? Did they have the courage to ask the terrifying question that nobody wants to ask - do we really need to develop this and the added fortitude and singular vision to come to that conclusion on their own?
Maybe I'm just missing the bigger point because at the end of the day, I doubt I'll ever be the Le Corbusier of software development and I'm just totally projecting here.
I believe that it is possible to overcome the fantasy/reality impedance, but nobody's going to be happy when you do.

Supercharge your to-do list

Over on the sinister secretGeek log, Mr. Geek's singing the praises of a text-driven todo file as a make-shift means of communication between multiple (two) developers through a source repository.
I've done the text todo file thing in the past too - it's drop-dead simple and it works.  I'm sure some people are aghast, but do you really need or want to fire up Excel or Project to track tasks?  Do you want to spam one another with e-mails tracking the itches you're scratching as well as what you're getting done?  It's imperfect, but it's easy and it works with a couple people.
That said, the concept of a shared text file is sort of... barbaric.  We live in the age of The Internets and The Internets have newer and better and shinier for us.  A wiki would do a good job of replacing the t-file; you can tag items and search and find stuff, plus it has built-in revision control so you can easily cut and paste or clean items off of your pages and they'll be available to you later if you didn't mean to delete them.  Not that I'd ever make a mistake like that.
But who wants to set up a wiki?  You've got to install the package, you've got to work out the dependencies and then have a way of securely publishing it so that only the right people can see it.  For two people, this absolutely feels like overkill.  But still... a wiki sure would be nice.
So, uh.  Why not use TiddlyWiki instead?
For those of you not hip to it, TiddlyWiki is a standalone wiki, implemented in an HTML file and it works splendidly.  There's a GTDTiddlyWiki out there if you've drank the GTD Kool-Aid (I haven't).  I don't know that it has all the internally-implemented revision control that a more full-fledged wiki has, but it does have tags and search features built right into it and it requires nothing more than a browser (it's just an HTML file, guy) but if you sync it up with your source repository often enough, hey wow you've got revision control there.  Nothing more to futz with and you're still sharing a text file between developers.  It's just a shinier text file.
Or you could hang back in the stone age.  Hey, your call.

I have a man-crush on Subversion.

I've got a big problem and I'm not afraid to admit it, so here it is - I've become obsessed with Subversion. For honest, really.
I'm a .Net developer, so this is sort of a problem - why not use Visual SourceSafe like everyone else? I mean, it's good, right?
I guess in the sense that it sort of works, yeah. But on Windows, the combination of Subversion and TortoiseSVN is so very very nice that once you go with Subversion (SVN), you won't look back. Actually, strike that. I guess you might look back fondly on VSS like you do other apps that took their design pointers from their fellow Windows 3.11 programs and that cause something just short of physical pain used over a WAN connection if you'd like.
If you're a Windows person, installing Subversion can be a bit of a mystery. You'll ask The Google about it and it will tell you odd things like you need some SVN service (that has been deprecated) and eventually you'll find a text file that explains how to install SVN as a Windows service with the newer revisions... sort of. But if you're like me, you don't want to read a poorly-written, incomplete text file that doesn't apply to you, you want results and you want them now.
So here's how you install Subversion 1.4.3 (the current version) on Windows.

1. Hit up Subversion's site and download the Windows version of the application (you want the 1.4.3 setup executable)
   
2. Go to TortoiseSVN's internets site and ask it nicely for a copy of TortoiseSVN
1. If you're running Windows 2000 and not XP/Server 2003, now would be a good time to download a copy of SC.exe
   
3. Install Subversion (into c:\subversion rather than underneath Program Files), then install TortoiseSVN (reboot if it asks you to because we are, after all, running Windows)
   
4. When you're ready, drop to a command prompt (win+r->CMD) and issue the following commands
1. cd\
2. svnadmin create svnrepos
3. sc create Subversion binpath= "c:\subversion\bin\svnserve.exe --service --root c:\svnrepos" start= auto depend= tcpip
5. ???
6. Profit!

So what did you do there? Well, you created a new SVN repository (the place where the files go) named svnrepos directly under the root. And then you used SC, service controller, to install an auto-starting instance of the SVN server as a Windows service.
What now? Fire up TortoiseSVN's repository browser (open Explorer, right-click on something and it'll be under TortoiseSVN's new context menu) and connect to "svn://localhost". You should see an empty repository and that means that the magic is there waiting for you. You can create directories here or you can import a directory (put it under revision control) and create and add directories.
Still not sold? Here's some of the reasons that I made the jump.

1. Group-based, directory-level access control
1. Imagine - QA can look, but can't touch (and you can't touch their scripts either)
2. Pre- and post-commit hooks
1. No more check-ins without comments attached; the server swats anyone who tries it (yes, that's a pet peeve of mine)
3. RSS feeds
1. VSS has a service that someone else wrote that sucked a little less when I made it multithreaded, but it still sucked (no offense as I was impressed by the mere fact that it existed). SVN's is sane and performant.
4. Statistics
1. Lines of code! Code churn! Developer stats! Way more fun than it should be for the procrastinator in all of us.
   

Don't you want to feel like you've accomplished something today? Get your Subversion on, kids.

10 I AM GOOD AT BASIC 20 GOTO 10

HELLO WORLD
I'm Dave, your, uh. Host here?
I'm a software developer from the wilds (OK, not really the wilds) of New Hampshire.
I'm embarassed by the code I wrote 3 months ago, let alone last year, but what can you do? Live and learn and go out there with a chip on your shoulder because there's always room to grow.
I'd like to think that after close to a decade being gainfully employed hitting keyboards, I've finally wrapped my head around the software development process a little. And in wrapping my head around it, I've seen that there's forces beyond beautiful code that determine whether the software I'm helping to architect and develop works or is a stillborn mess.
I'm trying to come to terms with that and the ugly sensation that keeping up with software development is a red queen's race and that maybe if I had some say in how the software was managed maybe I'd be able to do something about it?
I like music.
I like to read.
I like to ride my bike.
I like to not get hit by trucks when I'm riding my bike.