Uncommon Sense (for Software)

Developers as Chefs

The vast majority of developers believe that form follows function. They say things like, "Who cares what it looks like! As long as it works." They write-off user interface design, aesthetics and ergonomics as "graphics and icons".

In high-end cooking schools, the chefs spend a considerable amount of time learning as much about presentation as they do about the cooking itself. Why? It adds a tremendous amount to the user experience. It makes you feel like you're about to eat something special. Something that a lot of care and quality went into. (Something perhaps, that you'd even be willing to pay a premium for.)

Imagine if chefs said things like, "Bah! Why worry about presentation? It all comes out looking the same anyway!" I'm not sure I'd want to eat at that restaurant.

The difference between rocket science and software development is...

...not many people claim to be rocket scientists but everyone thinks they can design software.

It's nearly impossible to be a great designer and a great coder at the same time.

Anyone know the statistics on how many people can or can't pat their heads and rub their bellies at the same time? Even if you can, you have to admit, it takes significantly more concentration and focus than you would guess, for something that looks so easy (when someone else is doing it). And we all know that it has something to do with our brain wiring, some of which we are born with and some of which we learn (and re-wire). I always find it interesting when you come across another activity or two, that exhibit the same characteristics.

Like product design and coding. There are lots of great coders out there. And lots of great designers. There are very few who are both. But this post isn't about how product design (usability design, ergonomics, aesthetics) is different from implementation (technical design and coding). It's true that you rarely find one individual who has the sensitivities and skills to do either design or coding really well. But let's assume for a second that you are lucky enough to snag one (congratulations). I propose to you that even though this person has the skills to do both, doesn't mean you should let them.

The real value of such a person is that they have the capability to do either function even better because they have a very good understanding of the other. And, after all, these are symbiotic skill sets. A really wonderfully designed product is still crap if it's buggy, slow or doesn't scale. And a rock solid, fast, scalable system is useless if people can't (or don't want to) use it. So we know that a successful product needs an equal measure of both.

What I find interesting is that I have spent years doing both of these activities - designing and coding (not to mention the managing, wrapped around both). Even though sometimes I have been forced to be intimately involved with both at the same time, I can't escape the feeling that I wasn't doing myself any favors. You might be tempted to think that having a single brain responsible for the design and the implementation would be wonderful. Think of the efficiency! I believe it has quite the opposite effect. And it has to do with "automatic compromise". In this case, automatic = bad.

The great thing about having a separate designer (let's assume that this person has some understanding of implementation so they don't ask you to build the boat upside down), is that it frees both parties up to start with the "perfect world". In a perfect world, the designer thinks, we would build it this way... In a perfect world, the coder thinks, we would implement it that way... Now, they can come together to discuss any issues with how the design makes implementation difficult, or vice versa. They can negotiate. They can escalate. Tradeoffs that are made are transparent because both people discussed and agreed to them. Maybe they were even documented in case someone asks later? (ha!)

The trouble with trying to squeeze both activities into a single brain is that for each of the million little decisions you have to make while you're both building and designing, is that you are always in such a tempting compromise position, that your objectivity gets ruined while you're "in the moment." If you're making big design decisions while your head is immersed in coding and you're frustrated because something isn't quite coming along as quickly as you thought (imagine...) or because you've hit some unforeseen technical snag, what do you do? You design in a compromise, just so you can get going again, or make up some lost time. Do this a dozen times and soon you've got a mediocre design and mediocre implementation. I've written about when not to compromise before.

There is a big advantage in being able to focus on just the design (leaving implementation details to someone else), or just on implementation (leaving the big usability decisions to someone else and being free to say, "just tell me what you want it to do"). You both get to start with the "perfect world" scenarios, and then come together to find the smallest possible compromises so that you both get to end up with something that is as close to your original concept as possible.

The funny thing is, even though it is tough to describe the explanation for why it is so tough to be great at design and implementation at the same time (as I've just tried to do), is that the rationale (although interesting), doesn't really matter. The outcome remains the same even if you can't really explain it. You'd think that if you can either pat your head, OR rub your belly REALLY well, then it should be a simple matter to do both at the same time. Not so much. And even if you can, you're likely having to exert a significant amount of extra focus and concentration just to avoid rubbing both or patting both, instead of rubbing one and patting the other. And any activities that require THAT much concentration and focus, are even more vulnerable to things like distractions and context switching, which we already know are big problems in software develoment, even for the simple stuff. It's a risky strategy from a product point of view.

The best possible scenario is that designers and coders get enough exposure to each other's worlds that they can truly empathize and avoid big incompatibilities with each other's goals, but that they still get to focus and become specialists. That way, when it comes time to make those compromises, you'll know it each and every time, because you'll be sitting down to discuss and debate them to the best possible outcome.

Where you put your padding makes a difference.

Padding schedules for risk is not an incredibly new strategy. But to do it properly isn't as obvious as it might seem. When you're sitting down staring at a schedule, most people think they're being pretty clever by tacking on 30% to the end of their schedule and calling it buffer. There are a number of hidden problems with this approach.

Firstly, big bosses are trained at management school to go right to the end of a schedule (or budget) and slash anything that starts with "B" and ends with U-F-F-E-R. That way, they feel like they're leaning on people to "get the best/most" out of them. (Which is also a rookie management mistake, but that's another topic altogether.) Want to thwart this bad habit? Rename all buffer items in a schedule with things like: "Recalibrate the discombobulator" - that will throw them off track for a little while. I'm only half joking here.

Second, in pure* software development, any buffer less than 100% probably isn't enough in many cases. (* I say "pure" meaning higher degrees of complexity and invention versus "content development" which accounts for the bulk of standard commercial web-site development.) You may be better off thinking in terms of multiples. Even if that's not the case for your particular project, your buffer time (i.e. "oopsies") isn't likely to get used all at the END of the project. It'll more likely happen in little pockets throughout the project. Which brings me to my 3rd point:

The release date isn't the only date worth protecting. Besides when the quality control phase of your project starts (which is a HUGE milestone), there are likely components, tiers, or other important dates within your schedule that you're trying to predict the finish date for. Proper padding for risk should be sprinkled throughout the schedule so that when a slip on some small component does occur, there's enough elasticity after it that it won't linearly slide the remainder of the items off the chart. This is important because there are likely other dependencies in your schedule where certain activities are being co-ordinated and planned around smaller phases, components or milestones inside your schedule. The more protected they are from individual slips, the easier it is to plan around them on a continual basis.

Of course, it's EASIER to just tack on 30% to the end of a schedule, but easier isn't always better. This is where your choice of scheduling tool can have a dramatic impact on making your schedules stronger and your life easier. For example, Devshop automatically squeezes in little bits of risk padding after tasks by using trends it has observed with respect to the things that most often cause schedule slips: inaccurate time estimation, and dealing with distractions. Having these 2 top schedule killers accounted for in little bits and pieces sprinkled throughout your schedule gives you the most resilient schedule, for the least amount of work.

Less is More vs. More is More

Joel writes:

Making simple, 20% products is an excellent bootstrapping strategy ... What works for bootstrapping, I believe, will not work as a good long term strategy...

Alec writes:

Why do hot-tubs come with sound systems? People buy features. You may not need all those features. You may never use all those features. But you can take comfort in the fact that they’re there, knowing that you got value for your money.

We all know the "Less is More" strategy being popularized by 37signals.

Some very smart observations about the merits of both more features and less features. How can these smart people have conflicting opinions about which is better, less or more?

Something's missing.

It's the experience level of the user. And that changes over time. Newbie users LOVE simple products because they're not intimidating. They're easy to get started. They're cheaper to buy. When your needs are modest, a simple tool seems like a Godsend. When your needs are complex, simple tools look like toys and feel like chains holding you back.

Simple products (in this context, meaning less features) are not unilaterally better than complex products (in this context, meaning more features). Nor are complex products unilaterally better than simple ones. It all depends on where your users are in their own understanding and needs, related to whatever problem your product solves. Beginner users with simple needs love simple products. Sophisticated users with advanced needs view simple products as limiting and frustrating.

The important thing to remember is that beginner users eventually become advanced users. Oh oh. Now what do you do if all you have is ONE product that is either simple or advanced?!

(By the way, complexity and feature count can be decoupled with good design, but that's another topic altogether.)

Personally, I view a user's needs as a kind of evolution. The needs start off simple until the current product is mastered, and then users often want more features as they feel the need to excercise more finite control or power over their tool. If you give them this, then the tool no longer resembles the original "simple, elegant" design you first had, and you've simply traded beginner users for advanced ones (instead of adding new users).

What's a software designer to do? Hmm, the words "one size fits all" seem to be whirling around my brain - like somehow they may be responsible for this conundrum.

Personally, I believe the best solution is to stop trying to design a single user experience that is exactly the same for the beginner user as for the advanced user. Once again, in trying to please everyone, you risk pleasing no-one. Know your audience! If you must please users at varying levels of sophistication, the best strategy I've come across is to either split your product's user interface into "modes" where the user can select their own level of needs (don't ask a user how sophisticated they are: they'll always say "advanced"), or even consider splitting your users across different physical products that serve basic or advanced needs. In other words, the user experience should be like a highway on a journey of learning. Give people a couple of different entry points and let them merge wherever they feel is appropriate. Then let them grow up with the product and show them that when they're ready, you've got the next step covered too.

As with all good things however, there is a cost. Having separate user interfaces, or separate products, requires more planning and design, and more development effort - but wait... You're getting more customers out of the deal right? And quite possibly even happier, more loyal ones too because you've more closely aligned your user experience with their current needs. Seems like everyone wins to me.

Many people might argue that it's too expensive to segment users based on sophistication levels for a single product, or to have multiple products for different levels. However, there is no arguing the fact that niche players in many product categories are stealing customers away from general purpose players in those spaces. In fact, one could argue that the general purpose approach only works as long as the space is not big enough to support those separate niches, and only as long as the barriers to entry in that space are so high that niche vendors can't get in the game and take away those customers. For most software related fields today, the barriers entry are low, the markets are big (meaning they will support segmentation).

So if customers are being presented with a choice of products from different vendors at varying sophistication levels anyway, why not have those product choices under the same vendor's roof, and blended to look like they all come from the same family? Maybe ease the transition from beginner products to advanced ones?

Why do "enterprise" vendors ONLY make big, complex software? Why do "Agile" vendors only make small, simple products? Once a company builds up an expertise in a particular domain, why not offer a choice?

I believe that in most cases, it's because the teams building the software also grow up with the product and gain more and more experience and sophistication in their own domain, that they leave beginner users behind as they project their own advanced understanding onto the product's user interface. This process continues until they've left some users behind and have created a barrier for new users to jump on board.

We need a "leave no user behind" philosophy in product design!

Zots, Story Points & "Pure Dev Days" vs. Days, Weeks, Months

One reader recently brought up the subject of using Story Points as a unit of measure for the "effort" or "duration" of a feature or capability, rather than estimating effort in days, weeks or months. You may have stumbled across this practice if you are following one of the variants of the Agile development movement.

For those of you that don't know what a Story Point is, it stems from another pillar of the Agile process. The idea is that you get users to describe use cases for the application they'd like (called "User Stories"), and they serve as specification of sorts. Story Points are used to quantify the effort (and indirectly, how long it will take to build). The point of all of this is to have some way of trading off one feature request against another. If you want a new feature that would cost 10 Story Points, you may need to drop 2 others at 5 points each. It's a "cost" system.

I'm not a big fan of this unit though, because I believe it's an unnecessary level of abstraction. There isn't any clear advantage that I can find in using a new abstract unit instead of just plain old days and weeks. The trading still happens the same way: "Want something that costs 10 days? Drop two others that cost 5 days each."

The danger to the stakeholder that's asking for the feature is that they're being forced to work in a unit they don't understand. It forces them to try to learn a new piece of jargon that seemingly hides what they REALLY want to know, which is: how long is that going to take? It seems extra odd to me because part of the Agile method is to try to bridge the gap between users and developers, which is why the whole "storyboarding" theme exists. But then turning around and using an abstract unit of measure for "effort" seems to be inconsistent with that, and actually clouds the topic of effort or duration. It seems to keep users in the dark about the "real" cost of a feature (time). Plus, the benefit of using real time units (days, weeks) is that stakeholders can see that development is actually a pretty slow and time consuming thing. Sometimes it really can take you 10 days to "just add a button". By using real units of time, you "expose" them to this reality.

What really makes my Spidey-sense tingle about an abstract unit of cost like Story Points, is that it's value relative to time changes with the wind. One month, each Story Point might be 3 calendar days. The next month, it might only be 1 day.

Another similar practice is to use "Pure Development Days" as the unit. This I like better, but still not completely. I like this better because it uses "days", which we all share some intuitive understanding of, but it's still a little abstract because of the built-in disclaimer: "Pure Development". What is Pure Development? Does it even exist? It's trying to demonstrate that over a period of 2 calendar days, you may only get to spend 1 day worth of development across those 2 calendar days, because of other things that come up that distract you from development. So, better, but still not quite there in my books.

The risk with Pure Development Days is that normal people will subconsciously drop the "Pure Development" and just think you're talking to them about regular old Days. Because that's all that coders do is code, right?

I do very much like the fact that with Pure Development Days you can derive a kind of productivity metric. Like, for every 3 days we get 1.5 days of solid development time, and 1.5 days of miscellaneous "admin".

For those of you who've read about my pet metrics of "Time Estimation Error" and "Distraction Rate", you may recognize that Pure Development Days is kind of like Distraction Rate, turned upside down. A Distraction Rate of 50% means that a developer spends half the time doing things unrelated to the core project (development), so if you want 1 solid day of development, it's going to take 2 calendar days. This is really a similar formula to Pure Development Days, but it flips things across the equals sign for good reason.

By using (plain old) days as the unit of measure for effort/duration, you can set expectations with stakeholders about when (on their calendar) they can have something, as well as the relative cost of something (2 features @ 5 days = 1 feature @ 10 days), so long as you're internally marking up your numbers for Time Estimation Error and Distraction Rates before quoting the bottom line to your stakeholders.

So, you internalize these fancy metrics inside the dev team, but get you speak plain english with your stakeholders, and still get the extra visibility into "productivity".

Why Good Enough Isn't - Quantifiably.

On Monday night, Ottawa had its first CaseCamp. One of the presenters was Mitch Brisebois of TrueContext (company) and SensoryMetrics (blog).

I've long believed that "Good Enough Isn't". It's just one of those things I've felt in my gut and I've tried to use as a guiding philosophy when building products. Trouble is of course, not everyone shares that belief. In fact, I'd say the minority do. The much more popular stance is, "it's good enough, ship it now", or it's cousin, "is that extra polish REALLY going to make or break the product?" (shudder).

Mitch whipped out a slide that I though was a wonderful illustration of what happens when you adopt a "good enough" philosophy with product development.

It goes something like this: If the user experience with your product is uneventful, they'll think it's "OK", probably won't remember you, and you'll have a deficit in terms of loyalty with that person.

Yet, on any modern software business plan, you'll invariably see themes like "viral adoption" and "word of mouth" dominating the marketing section. Hmmm. But the chart says you need "WOW" to get the "share with many" reaction. Morale: if you're aiming for anything less than WOW, you're aiming too low.

Choose Your Units of Measure Wisely

I have a pet metric that I call Time Estimation Error. It's the percentage of time that a person is over or under, on average, for all of their time estimates over a given period. For example, if over 10 tasks, a person estimated 20 days, but took 30 days to do, their Time Estimation Error is 50% (overrun).

This kind of tracking is built into Devshop so that it helps you get to know people over time and build better schedules by automatically adjusting for these kinds of factors. So eventually, when someone tells you something is 10 days work, you'd know that it's likely 12 or 14, depending on that person's accuracy rate.

It occured to me a few weeks ago that perhaps a percentage is the wrong unit of measure for a factor like this. What's in a unit, you ask? Well, for one thing, perceived boundaries. Sure, we've all seen numbers like 300% and 400% (figures that are more than the soft maximum of 100%), but if you blindy ask someone what they think a good percentage is for something, anything, I bet there's a statistically better chance that they'll give you something within the bounds of 0% to 100%, not even considering anything over 100% - unless you really push them to think hard.

Now with estimating time on a software project, typically in clumps of days per feature, my experience has been that people are off by as much as several times their original estimate. Like a 2 day task that actually ends up taking 5 days (= 150% overrun or a 2.5 times multiple of the original estimate).

I'm beginning to think that a multiple (of x times) or decimal value would be better at getting the point across, than a percentage which tends to "lead" people into giving certain ranges as a response to a question.

Of course, if Devshop's tracking it for you then it doesn't matter, you'll get an accurate figure anyway, but I think the unit of measure chosen to track a metric like this has a bearing on the results you get, if you're asking human beings for the answer (guestimates).

By the same reasoning, when a lot managers "buffer" for unforseen difficulties during a software project, you'll often see them use percentages - like a buffer of 20% for some particularly risky component. I think in many cases people would be better served by thinking of risky parts of software projects in terms of multiples, as if the not so risky parts of a software project (an oxymoron) aren't tough enough to nail time estimates for.

Why Craftsmanship is More Important than Ever

I've often had discussions with people about the importance of design in software. By design, I mean things like: usability (= learnability + productivity), ergonomics and plain ol' appeal (after all, you want people to use and like your software don't you?) I've been known to drive developers nuts moving things around on screen, and even became known to a few as "2 pixel boy", because I'd always be asking developers to move their textbox labels up or down 2 pixels to make sure the baseline of the text in the label matched the baseline of the text inside the text area. Basic stuff in my opinion, but continually overlooked by many.

Clearly there are a couple of camps on the relative importance of design. You know, the form vs. function debates. I won't recreate that debate here, but I am pleased to see what I think will be a new bias being adopted by the general public in the coming years.

I believe that "elegance" is going to make a big come-back. I think we're exiting the age of utility development (having laid working infrastructure) and entering a new age of craftsmanship.

From a business perspective, here are the trends I see that I believe are the signals of a shift on emphasis from "cramming features onto the brochure" to "crafting" an elegant solution to each software problem:

1. "Individuals" (not just companies) can finally produce software: Large groups that produce software tend to move towards a manufacturing or assembly-line organizational structure. The reason being, this is one of the few ways (maybe the only way?) we know how to get a large group of people working together on a single complex activity like developing software. We each take our little piece, and no-one holds the "whole" in their mind at any given time. By contrast, the individual (or small team) tends to gravitate towards the "craftsman" style of work. Everyone can see the whole of what they are building and how each of the little pieces interact with eachother to form the whole user experience. There's a higher degree of association between builder and product, which leads to pride in worksmanship, which leads to higher quality design and products. This simple "bias" in how we behave depending on the size of the group, will influence the outcome of our designs.
2. The people that used to buy the software didn't actually use it; now the users buy the software: Most business apps historically have been purchased by CEO's, CTO's, IS departments or managers on behalf of their users. This was largely due to the fact that once you bought a system for your people to use, you were "locked-in" with file formats, protocols and other various reasons why you simply couldn't live with having more, smaller apps floating around your company. Each app required an investment in training, so you'd want to make sure you had to train your people on as few tools as possible. When purchase decisions are being made by people that aren't actually going to use the software, the only major decision points are things like: the demo, the brochure, the price per seat. Software was purchased at the top, then handed down to the people that were told to use it. Ergonomics were considered frivolous. There was no self selection going on. Now that we're in the trough of disillusionment with big shaggy enterprise software, people are moving towards smaller independent apps that can simply talk to eachother (with less upfront investment, and much lower price points). When users buy their tools directly, elegance, usability and design become MUCH more important in the purchase decision.
3. Who HASN'T used a computer these days? We've finally hit that point where software is everywhere. First-time users are nowhere to be found. Using the "computer" is no more thrilling than using a fork. The computer is so commonplace now that is has become invisible (almost) and the only thing people see is the software - it defines their experience to a large degree. I remember when I first started riding motorcycles. I was so thrilled just to be on the bike that it didn't matter how cold it was outside, or if it was raining, or if it was boiling hot underneath my leather. I rode because it was thrilling. Then the thrill wore off... My view of the bike changed. I now saw it not as novel, but simply as a means of transportation. When that happened, it was always too hot, or too cold, or too inconvenient to carry personal items (or a passenger). I stopped riding. People have used enough software now that the thrill has worn off and they are much harder to impress. They aren't as easily hypnotized with all the fancy items on the feature list and the mere promise of new capabilities. They have seen well designed products and they have seen crap. And they are better able to discern the difference before they make their purchase decision. All the promises on the brochure aren't enough to cinch the deal.
4. Try-before-you-buy is now mandatory: at least for most product categories. It's not just the list of features, but the initial experience after trying the product for a while for free that determines likelihood of purchase (or in the case of in-house software, willing adoption). The power has shifted from the vendor who could sell products without actually letting people try them, to the consumer, who will try it first and make up their own minds about the wild claims made on the web-site.
5. Software has moved from the early adopters to the majority: I know it sounds crazy to think that software wasn't already in the majority for the last several years. And maybe for businesses it was more-so. Consumers are now software connoisseurs too though. When something is at the early adopter stage, its level of polish and craftsmanship is less important. Fanatics, hobbyists and the curious will "administer" their own software. They'll do crazy things like rebuild kernels and configure until the cows come home. Now, people want stuff that just works. That's a lot harder to build and requires a lot more attention to detail and to the user experience in the design process. Products that just work are now being chosen over competing ones that are cheaper and have more features! This is a new emphasis coming from our customer bases.

Personally, I think it bodes well for the future generation of software products. I say bring it on! It's an exciting time to be a developer.

Use Reverse Engineering to Your Advantage

A while ago, I wrote Building it Front to Back, where I described the process of developing v1 of Devshop, starting with the user interface and working backwards through business logic and into data storage. It worked REALLY well that way.

Today, on the drive to feed my Starbucks addiction, something else occured to me that might explain why it works so well (in case you're not already a believer).

Most of us in software development know that reverse engineering is WAY easier than forward engineering (building it the first time). That's because when you have a living, breathing model of it already working in front of you, you are free to examine it from any angle and run any kind of behavioral test on it (what does it do when I do this?). And, quantum physics aside, it is fairly consistent and behaves the same way every time for months-on-end (unlike some bosses or customers who love to change their minds daily).

What is really happening when you're reverse engineering something? You're fiddling with the interface (user interface for applications, or API for platforms) on the surface, because the guts of it aren't readily visible to you. You're pushing and pulling screens, always able to see what the "response" from the application is, even though you can't see "how it got there". Now, if you can't see how it got there, "how it got there" might as well not even exist! (It's magic.)

That's kindof like building it front to back. You've got the model there right in front of you, you can at least navigate anywhere you want to go, and with sample data, that's pretty darn close to "real" data that was generated from magic business logic that doesn't actually exist yet (or is hidden from you). So, what's the difference?

See, this clearly proves that building it front to back is LIKE reverse engineering, which we already know is easier (more consistency and less loose ends) and easier is good, therefore building it front to back is good. I don't know a mathematician who could have proved it better ;).

Huh. I wonder if customers changing their minds is a result of quantum leaping?