Estimating Software Development

Are We There Yet?

As an engineer's career progresses, it's more or less inevitable for her to have to do increasingly complex project management and interact with business folks . Much of the time, what this means is that somebody (usually selling something, either to customers for money or to the board of directors for approval and/or money) needs to know when Flanginator 2.0 will be released. Perhaps just as often, it means that somebody already sold Flanginator 2.0 (in beta, if you're lucky) on a contract starting six weeks from yesterday and they need to know what can be crammed into the next six weeks so they can tell the client what they actually bought. In non-dysfunctional organizations, an engineering manager is eventually called upon to answer a few simple questions:

• How long will Flanginator 2.0 take to build?
• How much of Flanginator 2.0 can you do to get something out by date X?
• What resources do you need to build Flanginator 2.0 by event X?
• Why is Flanginator 2.0 taking so long?

Ideally the engineer is summoned early on, before dates are set and products are sold, but in practice that's not always the case. This is where the art and science of software development estimation comes in. And it's a bit of a paradox, because engineers are both the best and the worst people to do this.

The Reluctant Leading The Blind

Simplifying grossly, it's helpful to see the typical web shop as a place where software engineers, the Makers' Guild, build things business people sell, and business people, the Merchants' Guild, sell things software engineers build.

Time (to market) and timing are everything to the Merchant, while quality, cleverness and/or craftsmanship are everything to the Maker; and both are completely reasonable. The sooner the Merchant gets to sell a product, and the more closely the product availability can be tied to some important externality (e.g. a trade show, a conference, your customers' budget calendar), the sooner the revenue rolls in, and the harder it is for the competition to catch up. Complementarily, the higher-quality the product, the more satisfied the Maker and her customers are, the more revenue rolls in, and the harder it is for the competition to catch up.

Note each guild's goals are exactly the same as the other guild's--make money and beat the competition. But the two camps are going about it from two very different perspectives: the Merchant is very concerned with time, shrinking it or molding it to fit into a complex web of external calendars and deadlines over which she has very little control. By contrast, time is the least of the Maker's concerns, because she has to worry about building a product that works with no splinters or dead-ends or a shaky foundation--it'll be ready when it's done, and we can't compromise code quality / scalability / employee morale / features / database structures / code reviews / our finely chiseled system architecture just to get the product out faster.

In the best-case scenario, this tension leads to a very brisk product release schedule with constant improvements to products that sell themselves because they're finely tuned to what the market wants. In the worst-case scenario, engineers hate the slimy loose-cannon idiots from sales, and sales people hate the scruffy maladjusted untucked nerds from engineering who couldn't sell a warm jacket to a naked Eskimo.

The Thanksgiving Dinner Parable

Taking my cues from a long-dead craftsman from the Mediterranean region, who used to get a ton of mileage out of ostensibly non-à-propos at all yet profoundly relevant stories about people and things unrelated to the question at hand, I'd like to step back from engineering and sales for a moment to try to get at the crux of the biscuit of software estimates, by considering the commonly-shared experience of the Thanksgiving dinner (at least here in the US; feel free to substitute any other magniprandial calendricality of your choice).

In very simple terms, a Thanksgiving dinner is a family gathering on the last Thursday in November during which a large quantity of home-cooked food is consumed, also at home, by nuclear families and sometimes Others (usually not until they have reached the Significant stage). The meal normally includes a very large turkey, cranberry sauce, mashed potatoes or yams, some non-starchy vegetable, stuffing, gravy, some manner of bread, pumpkin pie, and beverages. It is widely accepted that the average Thanksgiving convive will describe with the most fondness and enjoyment those events having involved the maximum amount of home-cooked items, especially when made entirely from scratch, as against, say, canned cranberry sauce or frozen Sara Lee pumpkin pie, which isn't half bad, if you ask me.

Now, if you ask a Thanksgiving dinner maker how long the whole shebang is going to take, you'll probably get a wide range of answers. A young, first-time cook might say "oh golly, I have no idea, it'll take at least a week, and it's already Tuesday!" as s/he rushes to the grocery store. A Thanksgiving veteran might say "I'd say a morning of shopping, thaw the bird overnight, a day of cooking, so let's call it three days." I'd bet some serious Thanksgiving dinner makers put a lot more time into it, while Thanksgiving dilettantes may devote just a few hours (or none at all and just go to the restaurant or order in). I'd also bet not a single one of those guesses will be near the time it actually takes when all is said and done. People are simply not very good at guesstimating how long things take, unless said things are very few, very well-defined and well-rehearsed, and immune to externalities like a flat tire on the way to the store, a gas leak, frigid temperatures adding five hours to the bird's usual thawing time, etc.

Of course nobody would ask the Thanksgiving dinner maker for a very, very specific estimate of how long it will take, or a very, very detailed breakdown of every little task with a time and a name attached to each. If you requested a Thanksgiving task list from a naive cook you'd probably get something like this:

• go shopping (2 hours)
  
• thaw the frozen turkey (36 hours)
  
• cook turkey (6 hours)
  
• make pumpkin pie (2 hours)
• etc.
  

In reality, though, what actually happens is this:

• drive to Trader Joe's (10 minutes)
• find a place to park and walk to store (10 minutes)
• shop (25 minutes)
• stand in at the register in the crowded store (10 minutes)
• go back to car, load trunk, return cart (5 minutes)
• drive to Safeway for the rest of the stuff (10 minutes)
• find a place to park and walk to store (10 minutes)
• shop (25 minutes)
• stand in at the register in the crowded store (10 minutes)
• go back to car, load trunk, return cart (5 minutes)
• go to the farmer's market because the asparagus was just ugly (10 minutes)
• shop at farmer's market (1 hour)
• get gas (10 minutes)
  
• go home (10 minutes)
• unload (10 minutes)

We've already blown the "go shopping" bullet point estimate (2 hours) by 75% (3 1/2 hours). I'll spare you the expansion of the rest of the list, as I trust the point is made--as absurdly detailed as the longer breakdown is, it's the only way you can get close to how long any single piece of functionality of your Thanksgiving dinner is going to take. The larger/fuzzier the piece ("cook turkey" is a lot more than just sticking a bird in an oven--there's stuffing, basting, gravy, turkey skin hydration and temperature monitoring, etc), the less accurate the ballparks inevitably are.

Many software engineers are Thanksgiving dinner makers, thinking in terms of blocks of functionality that often require a lot of work. And because writing software usually means building something that you haven't built before, there's very little directly applicable hard evidence in your past experience to guide you in your time estimate for the new feature. Some well-rehearsed tasks can be estimated very accurately assuming everything works (e.g. kickstart a new server on standard hardware), but that assumption itself is often faulty since, well, nothing actually works all the time--we're talking about computer hardware and software, and we're barely out of the Ford Model-T era of sophistication and reliability.

So one key to better estimates is to learn and practice the skill of breaking those chunks down into well-defined tasks that can likely accomplished by one or two people in a day or less. If that's too hard, break up your larger features into smaller feature subsets, and break those down into tasks. Use Post-It Notes, with names and time estimates on each of them, line them up on a wall, then add up the times--there's your time estimate. Of course it'll be rough, and three times as long as anyone expected, so that's where you start cutting features and grouping tasks into releasable phases that can be rolled out in daily or weekly increments, or major versions of your software over a longer period of time.

There are diminishing returns the deeper you go into details for your estimate; splitting up a day's work into eight one-hour segments (or smaller) requires a huge amount of upfront analysis and thinking that will most likely be inaccurate or irrelevant by the time you start, since you haven't started writing the software yet and today's guesses about which individual classes and member variables you'll need two weeks from now are mostly a waste of time as the features and implementation details will have changed three times between now and then. So save the very detailed (sub-1-day) breakdowns until you've broken up your feature set into phases, and each phase into bits of functionality, and don't tackle too much in advance--a couple of release cycles at the most, because the work you do today for phase 1 may turn out to invalidate the guesses you make about phase 4.

All that means is that software estimates are just that: estimates. The only time you can precisely say how long a project is going to take is after it's done, and even then it's rarely practical to be exact, because being exact requires either sneaky or overbearingly bureaucratic time-tracking shenanigans, and who has the time?

Note this doesn't absolve the Makers of the responsibility to produce decent estimates, to consciously work at improving them, and to make every reasonable effort to build quality products in accordance with what often seems like a completely fanciful set of arbitrary external deadlines. On the other hand, frank conversations need to take place with the Merchants so that truly arbitrary deadlines that only exist in a Merchant's mind are objectively and clearly separated from the handful of hard deadlines the blowing of which can have truly serious consequences, so that pressure, potential disappointment and ultimate recriminations are kept to a bare minimum.

Real and Fake Deadlines

In addition to estimates, a software engineer's job also requires becoming creative and conversant in the art of compromise. Do you really need the Flanginator to have an electronic stereo klaxon with 127 foot-switchable sounds, or will a hand-activated horn suffice? Does the Flanginator positively, absolutely need to be out and tested by February 12th, or is there flexibility?

Some compromises can't be done: a big turkey will not thaw satisfactorily in two hours. You also can't just eat cranberry sauce and nothing else. Often they can: maybe Whole Foods mashed potatoes are just as good as the ones you were going to make before you fell in the shower and sprained your potato-mashing wrist. Sometimes they're not worth it: do you really want to go to Whole Foods on Thanksgiving Thursday morning, or call in a caterer with 12 hours' notice?

So another key is to be honest with the whole team (Merchants and Makers) and distinguish between real and fake deadlines. Real deadlines are events or signed contracts where having some product is a requirement, like a trade show or a meeting to pitch investors. Blowing those is like having Thanksgiving on Friday--ça ne se fait pas. Sacrifices will likely need to be made all round if the timing gets tight (cut features, hacks, throw-away code). The responsibility is best shared across the team, and your Merchants need to be on board with (and shoulder some of) the sacrifices made to make the deadline. Fake deadlines are those features that just "need to go out tomorrow so this reporter who told me she might write a piece about us for next month's issue can see we're on the ball." Those are more like dinner with friends: no one will die if you skip a weekend, or hang on Saturday rather than Friday, or order in instead of home-baking your famous prime rib cheesecake.

No Eye-Rolling

It's hard to find organizations where engineers don't roll their eyes and complains "Jeez, sales sold something we can't possibly build again. Jill must be trying to max out her quarterly bonus / they have no idea what it takes to build that thing." Those organizations' sales folks are also more likely to wonder "How can we be expected to bring in revenue if engineering won't build products we can sell? Our customers close their budgets by November, so if we don't have Flanginator 2.0 ready to demo by October 17 at 2:17pm EST, then it's an entire year's work down the toilet." This is bad, but not very difficult to address.

Educate your developers and product folks by getting the sales folks' perspective on what the market wants. The sales force is on the ground, talking to customers every day, and has a unique perspective on what kinds of products can be sold, so sales should be involved in the product development. Even a small UI tweak being considered to make something fit more gracefully into a page can have a huge impact on the sellability of a product (maybe it means your paying partner's logo will look smaller, or be their name will be moved off to a less desirable position). The only worse thing than having to scramble to hotfix a roll-back of this change is getting a call from sales right after they hear about the tweak from their very angry paying customers. It's not fair to sales, it's not fair to engineers, and worst of all it's not fair to your paying customers. Get sales involved.

On the engineering side, invite your engineers to industry events, focus groups, and user testing; heck, encourage them to run some of those user-testing sessions. They're inexpensive and eye-opening, and nothing beats hearing the same three wishes or complaints directly from real customers.

Ultimately nothing beats product and business leaders with some technical sense, engineering leaders with some business sense, and engineers who are realistic and honest about what can and can't be done. Ideally the skill sets in a product development organization overlap a bit like this:

If you don't have that today, get started on it now, because your organization is a vital organism that must--and can--change, adapt, learn and improve.

Lolspeak in The Gap and Lowly Passengers

The Gap, now in Lolspeak:



Cf.



And:



Unrelated: why do passengers not deserve a single capital letter, when almost every other word does (Alameda ferry)?

Mozilla: Please Fix This

All the tools I use professionally are open source, with the exception of MS Office and Visio. My browser is Firefox, my email client is Thunderbird, and I manage my calendars with whichever calendaring program wasn't abandoned by Mozilla. By and large Mozilla software it's pretty good. It does the job very well much of the time, and competently almost all the time; but I do wish Mozilla had a little more UI sense and discipline to make better, clearer choices in their product development.

Tabs, Tabs, Everywhere
Thunderbird makes a big deal of its tabs. "Now with tabs, better search, and email archiving" is the main selling point on the download page:



Now, I'm all for innovative UIs, but did the world really need tabs for email? Email has been around for decades, and mostly mainstream for 15 years. Most consumer desktop programs open a new window when you open an email. It's pretty much the standard paradigm for desktop clients; web and mobile clients are probably making this paradigm semi-obsolete, but millions of people use desktop email programs every day, so it's not dead yet. And I don't think tabs are the way to go for email.

Sure, you could make the same argument about browsers: before tabbed browsers started gaining market share, new pages opened in new windows, but tabs have proven themselves as a superior alternative for many people. No argument from me; I used a tabbed wrapper around IE back when Firefox (then Firebird) was more unstable than Jeffrey Dahmer. But a browser has one primary function (viewing web pages), whereas email clients have a long history of letting you manage more than just email, with calendaring, to-dos, notes, and various other things. And that is where the tabbed design breaks down, and why emails shouldn't be opening in tabs. Note I don't expect the Mozilla people to read, care about, agree with, or implement any of these suggestions; after all, it took them years to fix the horrible usability error whereby you couldn't disable the functionality that marks emails as read when displayed in the preview pane. This is the one problem that prevented me from using Thunderbird as my email client. It's now an option, and disabled by default, if memory serves--thanks! But I'm going to gripe^H^H^H^H^Hwrite about it anyway.

It's a pretty common occurrence for me to get an email trying to set up a meeting, with "Does Thursday at 3 work for you?" That's not exactly convenient if you use Thunderbird for calendaring with the Lightning plug-in--now you have an email in a tab, and your calendar in a tab, and so you can't look at them at the same time. You can't alt-tab between them. You have to be keyboard-savvy enough to know that ctrl-tab is how you flip through tabs in a tabbed MDI program. Opening an email in a tab is also not as dramatic visually as opening a new window, so it was pretty frequent for me to open an email multiple times because I hadn't seen the new tab.

Tabs work well for distinct top-level features in Thunderbird: email, calendar, notes, to-dos, etc. Using tabs for sub-features of any of these breaks the hierarchy.

To their credit, Thunderbird lets you disable tabs for email, and that's the first thing I did, but it shouldn't be the default.

Drag Queens
While on the subject of Thunderbird, when dragging attachments onto a message window, why does the main message body not register the drop, while the "To:" section does? What kind of sense does that make?



Conceptually, the attachment is closer to the body of the message; it has nothing to do with the recipients. I understand why the whole address section is a drop target--that's because the attachment summary opens a little square to the right of the address section when you've added an attachment. But that square is nowhere to be seen until you've added said attachment, making it very non-obvious how you're supposed to attach files, especially if you've tried to drop a file onto the message body and failed. Come on, folks, this isn't hard. Get it right.

Tangent #1
Speaking of drag and drop: why do bloggers and web content creators still put up with the pre-2000 model of having to explicitly upload their photos via a dedicated upload form, and (if they're lucky) move it into place in their rich-text editor? Why haven't enough smart techies come up with a standard way to let people just drag a photo from their desktop onto their rich-text editor and have it show up in the right place, without having their text reflowed or mangled beyond repair?

I know the technical answer; what I want to know is why people aren't angry enough about it to demand a fix. Software should be transparent; exposing the nasty technical guts of the software by not providing an integrated experience is a sad cop-out, and the web community should do better.

More T-Bird
While on the topic of Thunderbird, another little thing that wouldn't hurt is to add a little intelligence into the parsing and display of the email. Apple's terrible Mail program does this remarkably well by automatically highlighting words like "yesterday" and "tomorrow" and showing a context menu to create events in their otherwise execrable iCal program; it also highlights contact information like phone numbers detected inside an email.

What I'd like Thunderbird to do is be a little smarter in the message display. When someone receives a message and highlights a section of it, then right-clicks on it, why not show a Search for xxx in your browser (using the default browser and search settings)? Even better: if you can detect that the highlighted string is an address, add a link to a map (a Google map would guarantee even more money for the Mozilla foundation); a phone number? Show a context menu to add it to your address book (together with sender's name and email), or overlay the contact's info if you can find it in the address book.

Yes, I know, I can edit the code myself and probably finagle my changes into the trunk, but why should I have to?

Pick One
One last gripe: I wish the Mozilla folks would just focus a little. Why have plug-ins, add-ons and extensions? Why even use that awful phrase "add-on", when "extension" is pretty clear (extensions extend the basic functionality, get it?) and a lot less techy? Similarly, why have both themes and personas? And why have Firefox, Seamonkey and Camino? Why not call them Firefox, Firefox Suite and Firefox for Mac, if you must distinguish, since they share so much of their rendering technology? What are the differences within those product families? Is there a difference? Most importantly, why should the end-user care?

With double-digit market share, Firefox isn't the bailiwick of basement-dwelling, Gentoo-compiling geeks anymore, so the old hyper-specific tech terminology needs a revamp.

Twitter: Unsafe at Any Speed

I'm a very light Twitter user. The value of the service is still mostly alien to me. And on the rare occasions I log on (or try to) and post something (or try to), something doesn't work.



I've actually been keeping track and found that Twitter breaks on elementary, "mission-critical", sine-qua-non functionality (like logging on, posting a tweet, or refreshing your stream; not the fancy stuff like uploading a photo or anything--I'm talking about operations without which there is no Twitter service) a full 66% of the time (that's two out of every three times I log on to Twitter).

I know scale is hard, but with over $150M in the bank and tech people begging to work for them, you'd think they'd have the absolute basics whaled nailed and rock-solid by now. As it is, they have more in common with my old 1983 Plymouth Horizon and its lovely (un)planned obsolescence, except people are treating it like it's a gold-plated Veyron.

Even their log-out functionality is broken right now:



I'll readily forgive a brand-new startup site in beta built by 2 unpaid engineers functioning on espresso and Red Bull throwing out erroneous 403s occasionally. But a supposedly major consumer site with $160M in funding, ~330 employees (as of 11/18/10), and dozens of engineers and operations people, trying to paint itself as a major force for marketing on the internet, at 11pm PST on a Thursday night? I don't believe for one second a technical staff that big, hip and passionate about their product is stupid, careless or incompetent--I'm just baffled. And yes, Twitter is big and has novel scale problems, but they're not the largest site on the web, and I don't remember a single time when google.com failed to perform a search or display their home page. Do you?

I know the world has gone completely insane about Twitter (another round of funding at a multi-billion-dollar valuation is supposedly in the works), but these guys seriously need to stop screwing around and solve their two biggest problems (stability and monetization) once and for all. Until then, I'll keep fail-whale-watching with the other haterz.

Encouraging Piracy, Part XLII

Queuing up a video on Hulu, I ran into this absurd notice:



Why should I be able to watch this video on my computer but not on my iPhone, or Hulu-enabled TV/Blu-Ray player, when I can watch other videos on any device? Why can I stream some shows on Netflix, while others require a physical DVD to be shipped to me? What kind of sense does any of this make to anybody? Restricting access in any way (not just to some arbitrary collection of devices) means smaller residual checks for actors, fewer royalties to the studios, fewer opportunities to display ads, and pissed off users who just want to watch a show. Everybody loses. The display device should be completely irrelevant. This is just as absurd as a book you can read in bed or on your sofa, but not on a beach chair or a commuter train. Or a CD that can only be played on players approved by the manufacturer. Nobody would do that sort of thing. Right?

In the meantime, people who download torrents get their content quickly and can watch it whenever, wherever they want, on any device they own, unencumbered by meaningless, arbitrary restrictions.

Other than the Soup Nazi, I can't think of any business that is so obdurately hostile to the people that support it financially. Doesn't anybody in the entertainment industry realize they'll keep shrinking and alienate everyone around them for as long as they make piracy the most attractive method for accessing their content?

Lying with charts

Charts can be very useful for capturing complex data and making it understandable. They're also very easy to use maliciously (or stupidly) to mislead and dramatically exaggerate differences. This chart (source) is such an example.

The leftmost green bar is 362 pixels tall, with a fairly tall point at the top. The rightmost blue bar is 52 pixels tall, with a somewhat flat point. This suggests the site with the green bar (a nice, warm, winning, "green means go" color) has almost 7 times as much traffic as the site with the blue bar (a cold color).

But if you look at the actual numbers at the top of each bar, you'll see that the short bar (6.149M) is only 2.3 times shorter than the tall bar (14.340M). That's because the y axis conveniently doesn't start at zero. The net effect is a 3x magnification of the actual difference. Yet the chart maker can still safely claim they're not lying, and indeed they're not--the numbers are right there, undoctored, for all to see. But the damage from the giant visual difference is already done.

Shrinking the scale of a chart like this so it doesn't start at zero is dishonest. Chart junk like fake-3D bars with taller pointy tops on taller bars only makes it worse. Zillow, you should be ashamed of yourself. Maybe your chief economist could come forward and disavow this piece of agitprop for what it is.

Disclosure: I led Trulia's Data Services team until August, 2010. I no longer work there, but still work on producing accurate data that informs and doesn't lie.

Cloudera Hadoop training

I just attended a three-day Hadoop training course and learned a lot. Glynn is a very good instructor and knows the system very well. I strongly recommend the course to anyone interested in writing data-processing software built on Hadoop (I didn't attend the system/operations session, so I can't speak to its usefulness to ops folks). And not just for the course materials, either, because so much of it is already available online: it's a great opportunity to block out three whole days to focus on learning a new technology, and that's not something I've been able to do since graduate school. So yay for the course, and yay for my employer for seeing its value and sending two of their engineers to learn new things.

Speaking of my employer, maybe you are or know someone with experience in data processing, data warehousing, Hadoop and similar technologies? If so, let me know.

(yes, I took the certification test, which was harder than Glynn had led me to believe, and passed) (yay)

On Open Systems

Free

The technical and societal significance of open systems in general and the free software movement in particular crystallized in an interesting light for me the other day.

During a recent conversation with another techie, we discussed the rapid emergence of Big Data, large-scale data processing and analytical insights that were once completely out of reach.

Then she asked me,"Why do you think this is happening now?"

A Simple Question

That simple yet pregnant question was not something I had pondered before, and yet an answer came very quickly and naturally: the free and open-source movements, or rather the free and open-source mindset, made it possible.

One major benefit that free-speech OSS brought to society was that it started millions of conversations on what to do, how to do it, and more importantly how to do it better, faster, and more securely, without any of the shackles of commercial software development. If your open piece is better than mine, I'll just put it into my product and make it better for the rest of the world. Without this openness and instinct to share ideas publicly in order to get at a better, more thoroughly vetted idea (aka standard), this extraordinary accomplishment known as the internet, which all of us are still in the process of inventing on a daily basis, would simply never have happened.

Hardcore GNU folks often pooh-pooh the importance of the free-beer part of F/OSS, because of their higher ideal of freedom and openness. But I think that's misguided. Free-beer OSS made it possible for millions of people to learn software development because they didn't have to choose between paying the rent and paying for a software license for an operating system, database, programming language, or IDE. They also didn't have to pay a dime to learn those languages, because OSS extends beyond software to free downloadable books, tutorials and help manuals. Where would computing be today if it weren't for those computer scientists, software developers and other technologists for whom free-beer learning was the only option?

Combine those two general benefits and you get to a point where a huge number of people write massive amounts of high-quality software to handle interesting, complicated ideas that goad hardware manufacturers into ever-faster progress on ever-cheaper devices, and you get to a critical mass of mental energy and pervasive hardware availability (read: large stacks of cheap computers) that gives rise to a true step change in how much we can do, how many questions we can answer, and how quickly and cheaply all of this can be achieved.

Open and Shut

That's not a factual, falsifiable answer and I'm not claiming to hold any deep scientific understanding of the truth about the state of computing circa 2010. But whatever one's opinion on the matter, I'd still say freedom, openness and community-driven standards in software and hardware development played a big part in making the computing world better, and so the real world.

Another way to put it, with all due respect to a great businessman and technology visionary who's still the exemplar of secrecy par excellence and won't embrace the virtues of openness: if the human body hadn't been jailbroken, Jobs wouldn't have a new liver. A bad deal for everyone.

Remove Twitter from Google search results

If you (like many others) like your Google search results unencumbered by the Twitter scroller Google added a while back, paste this into your browser's address bar:

javascript:(function untwit(){var r=document.getElementById('rtr');if(r){r.parentNode.removeChild(r);}})();


You can make that into a bookmark, name it "untwitter" and save it in your bookmark toolbar. You can then click on the bookmark to remove the scroller.

Only tested on Firefox 3.6.

Simplicity

If I Had a Hammer

It is sometimes said that software makes difficult tasks easier. Often the task is difficult not because the problem being solved, or the question being answered, is difficult per se: "I need to know when our users are likely to cancel their membership so we can send them win-back promotions" is a well-formulated, easy-to-understand, bounded question, and the answer is likely to be equally finite and easy to understand. The difficulty lies in gathering, compiling, and analyzing vast quantities of data in a timely, repeatable, reliable manner so that 1 billion data points coalesce into a half-dozen usable pieces of information. That's hard, and intractable unless you can process gobs of stuff really, really fast. Computers, and good software engineers, are really good at this sort of thing, and by and large you can never have enough of either.

All Nails

But a rampant trend in tech companies is the tendency to resort to technology and software to make easy tasks difficult.

Imagine a meeting room filled with 20- and 30-somethings, all endowed with solid educations, a solid drive to do the right things, and the disconcerting ability to explain the difference between TCP and UDP to finance people. The topic at hand: how to foster new ideas, team spirit, information exchanges, the kind of collaborative awesomeness you can sometimes get out of enlightened corporations and smart, enthusiastic people. The conversation might very well go like this:

"How about we set up a wiki page so everyone can contribute ideas and see everyone else's ideas? It's be really transparent and easy."

"Good idea! Once the ideas have coalesced a little, we can use Basecamp to see who's working on what and have real flexibility so new people can jump in and grab tasks they're passionate about without a big formal team structure!"

"Awesome! And since everyone's laptops have webcams, we don't need to have those big meetings--we can do ad-hoc catch-ups over Google Talk without everyone having to be around the office."

Those are all good ideas, and they would probably work for the project you're all working on. But when your entire team is reaching for ways to do things that wouldn't work during a power outage, or were not even remotely possible less than ten years ago, maybe it's time to take a step back and reassess.

"How about we just stick Post-Its on the wall over there?"

Why

I don't believe this kind of tech-centric groupthink arises out of malice or a perverse instinct to complicate--my money is on a combination of habit (we use our computers during most of our waking hours), a tacit post-industrial rejection of the trappings of the Old Way of Doing Things, and recency priming effects (the last thing most people used before the meeting started was a computer program reminding them they were supposed to have interactions with other human beings). All those factors conspire to obscure other modes of communication and collaboration so ancient and universal they simply blend into their environment, devoid of shiny surfaces and sleek contours, waiting to be used.

Tool Envy

I personally don't share the fetishism for tactile, low-tech (and wantonly expensive) implements so prevalent among financially independent Bay Area techies. It's tempting to ascribe this post-modern stylomania to the scribal equivalent of comfort food: in a fast-moving, high-tech environment, non-electronic utensils like #2 pencils and tidy notebooks with elastic bands to prevent intempestive openings provide the stressed techie with a familiar anchor to long-ago times when things were less complicated and responsibilities less burdensome, redolent of chalk and crayons and cookies and blood from one too many encounters with Jimmy the football player now safely stowed away in detention. Or possibly something phallic.

But when it comes to getting ideas, moving them around into thematic buckets, discarding the bad ones (physically!), refining the fuzzy ones, and making them available to everyone, passively visible at all times, omnipresent and inevitable in their glaring obviousness and gaudy magenta-on-high-gloss-white, nothing--nothing--beats Post-It Notes and Sharpies. Even the hard-to-read ones are useful, because they draw you in and make you think about what they might mean.

A Web-accessible company intranet / wiki / bulletin board is undoubtedly a very convenient way to share ideas with everyone--it's dynamic, accessible from anywhere at any time, and does away with any requirements of physical co-presence that the modern office tries so hard to make obsolete.

But unless you're crazy and never close any tabs in your browser, you probably don't have that project wiki open in front of you all the time, and it takes an active effort to be engaged in the project. By contrast, the cadaverous whiteboard and its bright pimply scribbles is both easy to ignore, like a light fixture or a garbage can, and impossible to avoid, by virtue of its large, immovable presence; walking past its hodgepodge of colorful puddles instantly draws your gaze and reminds you there's something interesting going on, without your having to do anything.

As for the additional benefits (constant, virtual availability)--are they solving a problem you actually have? If most of the collaboration happens between people who can reasonably be expected to be in the same place during overlapping business hours most of the time, do you really need 24/7 remote availability of your idea board? And if someone really is available at 3am, maybe what they need is a reminder to go to bed rather than a tool to help them work in the middle of night.

Rampant Complexity

This tendency is hardly the bailiwick of 21st-century internet startups. Take One Laptop Per Child for example: an interesting, beneficent idea, to be sure, but it seems to me investing in mosquito nets, immunizations, education, human rights and safety for every child in the developing world may cost less, be more immediately useful, and go a bit farther than giving a crank-powered Linux computer to a bunch of kids who could really use some clean water and the assurance they won't go blind before they finish reading their first book.

Beyond computers, the 1980s brought tremendous technological advances to musical instruments: synthesizers became mainstream, and piezo-electric pickups made it easy to amplify and record acoustic guitars--so easy, in fact, that the world collectively agreed to ignore their atrocious sound and to forget that sitting down in front of a single microphone really isn't all that hard.

Snatching Simple from the Jaws of Difficult

Note that this is not a paean to the Luddites. My main computer has a modern dual-core processor with obscene amounts of memory and more hard drives than I remember, because larger, separate hard drives mean worrying less about backups; but it's attached to a pair of giant 10-year-old CRT monitors, because the productivity and eye comfort of 3840 x 1440 vibrant, never-stuck pixels outweigh the benefit of lightweight, space-saving LCDs--the last time I physically had to move my monitors was over 4 years ago; space and weight savings are nice to have, but completely irrelevant.

I store recurring shopping lists into my phone (e.g., lists of hard-to-find books for the occasional bookstore trip, just in case), but jot down grocery lists on envelopes out of the recycle bin, because their useful life span (minutes, hours at the most) simply does not justify spending more than a second or two jotting items down. As long as I can scrawl "milk" faster than a phone, computer or PDA can wake up from standby, launch the shopping-list program and fix my virtual-keyboard typos into a sensible word, technology is a hindrance, not a solution. Sure, I could integrate the two lists and sync them to my Google account and set up reminders to buy Kleenex via SMS before I leave the office. But I have better things to do with my time.

Microsoft didn't come up with Sharepoint out of sheer boredom, perversity, or greed. Mailing Post-It Notes around doesn't scale very well if half your team is in Los Angeles and the other half in Manila. Of course technology is the right approach a lot of the time, maybe even most of the time. But if technology is good for many things, it's not necessarily good at them. Weigh the actual (not the hoped-for, or potential) benefits of using one method, against its implementation, evangelism, training, and maintenance costs. Don't pick a solution based on its ability to solve a problem you don't have, or almost never have. The burden of proof is on the complex approach, not the simple one--simplicity should always win unless there's a compelling reason to go the other way.