Uncommon Sense (for Software)

Kicking the Top Bad Habits in Project Management

I gave a talk to 30 local software developers last Wednesday, on the top risks in software projects and what to do about them.

We recorded the event and the video can be found here.

Speaking Engagement in Ottawa - Success!

The Bad Habits of Project Management event yesterday was a smashing success. Thank-you to everyone who was a part of it. Local community member An-Min Kuo has a summary and a Flickr stream of the event.

Software Development's Evolution towards Product Design

I just read a brilliant and well illustrated piece on the evolution of software product design. It takes you from the days of a lonely programmer with a technical problem to solve for themselves or possibly another buddy programmer, all the way through commercial product development. Check out this great storyboard for the gist of it:

Check out the full post for the narrative.

Was your product "assembled" or "carved"?

I've spent the last quarter re-designing the user interface for the Devshop product. The new design will be out in a couple months. During this process, I spent practically the whole year with my eyes wide open, looking for and noticing little cues to good industrial design along the way. I'd keep a list of screen shots of aspects of a particular product that I liked. I kept a list of ideas I had along the way for reference and revisited them all during the design process. I didn't just look at software. I looked at automobile design, furniture, interior design, print, architecture - any product discipline. I looked at video production, animation and writing too.

Good design is considered to be very subjective. I don't believe it is subjective. I think it is empirical and measurable. The problem is, people have a difficult time articulating what they like and don't like. They have a hard time dealing with the fact that unfortunately, a product isn't designed JUST for them, but rather for a market of people that hopefully all share a set of common enough needs and can therefore use the same product to fulfill some number like 80% of their needs. And because of these difficulties, people discount design as subjective because they can't reconcile why one person (who can't articulate why) likes something while someone else doesn't.

The other day something hit me. I think it's an easy way to articulate a set of characteristics in design that people gravitate towards, without consciously realizing it. It must have some root or explanation from anthropology or some very natural origin. I don't pretend to know the causal relationship, I've just noticed the trend.

It's what I'll now say is the difference between a product that looks like it was "assembled" (from various parts) versus a product that looks like "carved" from a single source material (like a single block of wood, clay or stone).

I have 3 examples to share: cars, laptops and finally, software.

Example #1 - Cars:

Assembled:

Carved:

Avalanche: The Avalanche is clearly "assembled" from various materials (metals & plastics), which jump from one to another along the exterior. The surface is lumpy and clearly shows things "bolted on" to the exterior. The coloring is high contrast, from light colors to dark colors. The shape is boxy, rough and has lots of cracks, crevices and protrusions.

Corvette: The Corvette looks like it was carved from a single piece of red metal. It has long smooth lines that are curved instead of at sharp angles. Very few protrusions and crevices, and nothing bolted on to the exterior. It is the ultra "low contrast" (in this case monochromatic) which furthers the illusion that it was carved.

Example #2 - Laptops:

Assembled:

Carved:

Dell: Latches, stickers, logo/emblem, rubber stoppers, lights and buttons all protrude, in different colors, from different materials along the exterior. It has a lot of visible seams, cracks and crevices. You can just imagine things being "snapped" together during assembly (and things "snapping" off as they catch things during use). The stickers aren't even straight.

Apple: Again, a single color is used to make it look like it is a single piece molding. Care was taken to remove anything that might stick out beyond the smooth surface. Even the screws on the edge have been carefully chosen and placed to not deter from the soapstone-like exterior. The power light, IR receiver and iSight camera (even the screws!) are all perfectly flush along the outside.

Example #3 - Software:

Assembled:

Carved:

Google's Gmail: Gmail actually makes my eyes bleed. It looks like it was cobbled together as an experiment or a prototype and nobody bothered to finish it. The inconsistent use of margins and whitespace, font-sizes and layout waste opportunities to visually group and convey information to the user about usage and importance. The color choices were obviously made by someone that is style blind and probably wears plaid with stripes to work. It looks like a hack.

Apple's iDisk: This iDisk screen struck me when I first saw it. It is one of the best examples of a user interface that actually looks like it was "carved" from material. The round, smooth edges, low contrast & subtle color changes (as if almost to signify texture change of a physical material rather than primary color change). The cleanliness of the margins and generous whitespace further indicates that is was designed rather than hacked.

The cues:

There is actually a morale to this story. We're surrounded by so much technology that we sometimes forget that we all come from nature. Most people have either a conscious (embraced) or unconscious (unrecognized) affinity to natural materials. Most people prefer curves to edges, simplicity to complexity (simplicity = fewer apparent material changes and protrusions, etc.). They may not know it but they will gravitate towards these things when given a choice, if everything else is equal.

I recently came to consider the following cues that can be used (or misused) to achieve a "carved" (natural) versus assembled (artificial) look in user interface design for software:

1. Curves vs. angles: Sure, sure, the Web 2.0 craze is experiencing a backlash towards rounded corners. The point is that people respond to smooth curves better to sharp jagged edges - again, if not consciously, then subconsciously, depending on how self-aware they are and how well they can articulate why they like or don't like something.
2. Contrast: : Lots of high contrast color changes mid-surface are going to increase the artificial or "assembled" looking nature of your product. A few changes is probably ok, but use them to convey something or shy away from them. The higher the contrast of the change, the more influence that change has to convey something, either intentional or by accident, so make it intentional.
3. Margins and whitespace: Even and consistent margins and gutters give a look of polish. Make these inconsistent, and your product comes off looking hacked. VERY generous use of whitespace can convey a feeling of cleanliness and simplicity, regardless of how many things are actually on a screen. The mean-distance between "things" on a screen (i.e. the gaps of whitespace) increase the overall perception of "smoothness" of the surface. The less white-space around things, the more "lumpy" it looks (remember all those protrusions in the Avalanche and Dell?).

Going forward, I think it's better to make your product look carved than assembled. People will respond better to it, even if they don't really understand why.

It all starts with recruiting.

Work to live or live to work? Do you consider yourself to have a job or a career? The answer to these questions can tell you a lot about a person. Too bad you can't just blurt them out and ask them directly while interviewing someone because it's too easy to see what the interviewer wants to hear and fake it. But as a recruiter, this is a pretty fundamental question.

The software industry is fairly unique in that it is filled with people who love what they do. Hobbyists. These people would build software whether they get paid for it or not. That means, if you're a "work to live" sort of person, in this field you're already below average. People that love what they do are much more likely to go the extra mile to be great at it. Given that it's also a very competitive space, over the years I've come to think of this trait as a filter when hiring. You'll never build great products with a team that "works to live".

Someone that works to live approaches their work with a "fulfill the requirements" sort of attitude and behavior. They may very well work hard while they're at the office and meet many of the "good general employee" criteria, but that's still not quite the same thing as someone that's in it because they love building software.

People who consider building software their vocation, are constantly absorbing what they encounter in their travels (things they liked about a particular product, new/fresh design patterns, tips/tricks/optimizations, etc.) and constantly looking for ways to apply these to the product they're working on at any given moment (mid-project, this accounts for a lot of scope creep - may be best to log them and plan them into the next release for the sake of a predictable schedule - but capture that enthusiasm, it's gold). They consider what they do their "craft" and are constantly looking to improve it for the sake of bettering themselves and their products.

The software business is all about the people. It requires virtually no materials, big iron equipment, even office space these days as the amount of software written in coffee shops is on the rise. One of the biggest differences between an OK product and a great product is the passion, creativity and craftsmanship put into it by the people building it - and all those extra miles they were willing to go to make the product great.

I believe that to build great products you have to start with great people (meaning: enthusiasts). This isn't a field where you can afford to just "get by" by fulfilling the letter of the requirements and moving on. It's too competitive. If you don't go the extra mile, someone else will and they'll eat your lunch.

Workaholics vs. the Passionates

Seth Godin has a short but very insightful post on the difference between a workaholic...

A workaholic lives on fear. It's fear that drives him to show up all the time. The best defense, apparently, is a good attendance record.

... and the "passionate worker":

The passionate worker doesn't show up because she's afraid of getting in trouble, she shows up because it's a hobby that pays. The passionate worker tweaks a site design after dinner because, hey, it's a lot more fun than watching TV.

Sure, not every business is the kind that can attract passionate people. Some jobs I'm convinced, are designed to attract people that have a special ability to "tune out" and leave their body ;).

But we in the software business are blessed. For a lot of us, anything software IS a hobby. We in the software business can arbitrarily crank up our team's passion by allowing them to introduce some of those "extras" into the product that really make it sing, but are typically hard to quantify on a feature list, brochure or spreadsheet - the ones that really make the product better for the user but aren't single handedly going to be the reason someone buys the product in the first place... (keep in mind I'm not advocating cramming your product with all sorts of extra "cool" features for the sake of it - I'm mostly talking about polishing the existing ones until they shine shine shine).

Here's a great example for a web app: cut/copy/paste of objects/records/thingies (not just plain text from one text area to another). I don't know anyone that would choose one product over another ONLY because it supported this feature, but it's one of those killer features we lost when we moved to the web and it is sorely missed! This is a very interesting problem for a developer to solve. Maybe the kind of thing that would get the team a little more jazzed than a product spec that is rife with compromise and corner-cutting?

The companies that build the cool stuff into their products (I'm thinking... Apple...) - those are the companies that people want to work for, and the products that people want to work on.

Frankenbabies.

A friend and I were talking about how sometimes in a small company, it feels like you move at a snail's pace due to a shortage of hands, minds & bodies. He was wondering about the possibility of chopping things up and outsourcing certain parts of the product in order to move the whole thing forward faster.

It's something I've been asked about before and thought it was worth jotting down my thoughts. As a general rule, I'm not a fan of chopping and outsourcing anything that is supposed to be a "core competency" of your business. If you're a software company, then your product, your software, is your core competency.

The reason I'm generally against it however, is not simply a matter of style or personality - there's a method to my madness. Generally speaking, chopping things up into modules (and worse), having them developed by people outside the core team is a great way of producing what I call a "Frankenbaby". That's a piece of software that looks and feels like it was stitched together from pieces of different products, rather than being "crafted" by purpose. You all know the kind of product I'm talking about.

But it's more than that. "There are lots of products out there like that and they're selling just fine.", you'd say. Well yes, but if you look closely, here's what you'll see:

Big companies and small companies sell things differently.

Big companies can sell Frakenbabies. Small companies can't. Big companies can get away with it because they sell on a completely different level than small companies.

Big companies:

• trade on an established (trusted) brand - you may not trust them to treat you like anything other than a number, but at least you know they'll still be in business tomorrow when you want to call them to complain and they're not very likely to just take your money and run like those vendors that used to sell XRay glasses by mail order on the back of comic books when you were a kid (damn them!)
• sell by the spreadsheet - the concept of "feature per dollar" comes into play and since user experience or quality are very hard to quantify, they very rarely make the spreadsheet
• sell to department heads who aren't even the actual users of the products they're buying
• usually sell based on services as much as software (especially with enterprise software)

Little companies however:

• sell directly to users (small to mid-sized companies) rather than to big company department heads, so user experience and quality are more obvious to the people paying the bill
• have no established brand and therefore have no choice but to "do it better" than the bigger guy just to close a sale (or get raped on price competing with an economy of scale)
• have to be careful about bundling too many services with the product to "finish it off" because the model is tougher to scale than a 100% product based solution

A lot of software companies try to act like big companies because they think that's how they will eventually "be" a big company. The truth is, you have to be really good at being a small company first before you get the chance to grow into a medium sized company, and finally a big company if you're lucky.

Small companies should choose the best strategy for their situation, rather than just trying to follow suit with the big companies - the same strategies do no necessary apply because the context, environment and players are different.

Plus, chopping & outsourcing does one other thing that can be very bad, especially for a small company: it robs you of the experience gained by doing it yourself. Experience counts for a lot, especially in research heavy fields. "Production"-type fields, not so much. Pump out widgets as fast and as cheap as you can.

Why I love Booleans. And hate them.

I love the Boolean data type.

True or False. Those are your choices. Nowadays, almost every programming language implements them the same. C is the only language I can remember that's still in use, that has some extra ambiguities because True and False are actually constants that evaluate to 1 or 0 respectively. So craziness like:

(true + true + true) == 3

can ensue. I love booleans because they are unambiguous and have virtually no boundary conditions to explicitly test for. Imagine the simple scenario of passing a parameter to a method. If it's a boolean, you have 2 test cases. If it's, say, an integer, you have to think about things like:

• Can this value be 0?
• Is it valid to be negative?
• What happens if I cast a decimal to it?
• What happens if I pass in another Int subtype (Long, UInt, etc.)?
• Is there a maximum value?
• If I'm passing this to, or receiving it from another app written in a different language, is the precision the same?

Ick. And of course, none of it gets into the documentation. (What documentation?!) All these ambiguities mean increased risk of bugs, or conversely, more testing time (whether you're manually testing or writing unit tests). Not so with booleans. I love booleans.

I hate booleans.

Things in the analog world are very rarely boolean, true/false, yes/no, is/isn't. There's a lot of "it depends". I hate booleans in conversations. They're limiting. They're conversation enders, not conversation starters.

Think about some of the big boolean debates out there in computerland these days:

• (Waterfall || Agile)
• (BigTestUpFront || QAbeforeRelease)
• (LooseTypingIsBetter || NoWayStaticTypingIsTheShit)
• (Interpretted || Compiled)
• (OpenSource || IntellectualPropertyRights)

The trouble with each of these booleans in conversation is that they are polarizing.

Son, if you ain't with us, yer aginst us!

The truth is, in the analog world, most things are actually spectrums or scales, rather than on/off switches. We'd all be wise to remember this. Each of those boolean debates going on out there are silly. Each of them really has a scale that should really be the topic of conversation.

Agile || BDUF (Big Design Up Front): is the "how MUCH should we plan before we start writing code?" scale. A little? A lot? Half way? Pick the optimal point for your context. How big is your project? How many people? Is it for resale or contract development? How likely are the requirements to change?

Compiled || Interpretted: Can we not achieve the performance benefits of compilation and yet retain the "view source" beauty of interpretted languages? Does bytecode take us close?

LooseTyping || StrongTyping: Can't objects still be created as a "class" but support some mechanism to override their default behavior in the 2% of cases you need that, so that we can still have the benefit of Auto-completion and Intellisense in our IDE's?

I hate booleans in conversation. We'd all be better off to be talking about optimization for context than right or wrong in each of these cases.

I bet that if we shifted to focus to scales & context and away from booleans, we'd find that the roots of the disagreements in many of these cases would be because we operate in different contexts and therefore there is no single right answer. That would enlighten us all.

Interesting Perspective on Agile Development

Mention the word Agile to anyone in software development and you're likely to get a strong reaction. The person will either jump down your throat if you even merely hint at suggesting at implying that it may not be absolutely, completely and without a doubt the most perfect way to manage a project EVER (blessed by the programming gods themselves). Or, perhaps the person will roll their eyes and prepare for a sermon (having been on the receiving end of one too many). These reactions are so strong that I've taken to "not talking about it", the same way I stay away from talking politics or religion while drinking in pubs:

"them's fightin' words, boy!"

Of course, there's more than just a little irony in the fact that "doing lots of planning before you start coding" has somehow become a laughable thought (you know, the idea that changing a Word Doc is easier than ripping out code if you change your mind early in the process). How did this happen? Perhaps in another post.

Anyway, I came across this post by Steve McConnell recently, about Agile - the pluses and minuses. Minuses?! What?!

Steve is thought to be one of those programming gods and as usual, his articulation is top notch. He seems to have a balanced, non-partisan view of the whole thing. He goes on to suggest that certain styles of management are more applicable to certain environments, but less applicable to others (commercial software development being one he mentions). Very similar to my own thoughts, though I marvel at Steve's ability to boil a complex topic down to its essential elements. It's tough to argue with the guy.

Who's Managing this Project, Anyway?

Software projects are different from other kinds of projects. I believe that while general purpose project management theory gives a good grounding in basic project management, it's not enough to be a successful software manager.

Software development is regarded by some as the most complex intellectual activity known to man. The model of "command and control", where there is a single "boss" who makes the majority of the decisions and hands them down to the "doers" doesn't work for software projects. The reason? The balance of the knowledge required to make so many of the decisions lies with the individual developers that are far closer to the implementation (the code) than the manager will ever be. Even more importantly, no single developer has a complete view of the system. Any good sized system has a team of developers working on it. Some where there from the beginning, some are new to the project and all have varying levels of knowledge of their own little pieces of the whole.

The role of a manager in the software world is:

1) The coach
2) The liaison to the outside world
3) The tie-breaker (in the case of disagreements amongst the team)
4) The one who holds the "whole" vision, freeing others to specialize in certain parts

What's a manager to do when the knowledge and experience required to make the bulk of the decisions rests with several different people on the team? How do you hold people accountable for work that you do not yourself understand? (If you've never spent years coding hands-on for yourself, please do not try to convince anyone that you understand software development. You don't.)

The answer is that it's actually the "team" that really needs to manage the project. The manager facilitates the team in doing that. For a working example of the team managing a process, consider the popular process of design and code reviews. It would appear that "management by the team" has snuck it's way into our lives, without us necessarily noticing it...

The design review process was developed to make sure that there was a consistent level of quality in the sub-systems that were being introduced into a larger system. Also, that the team at large would be initiated to this sub-system before it was introduced, for familiarity's sake. And finally, that the team could bring their knowledge of other related sub-systems to the table, to make sure that this new sub-system wasn't going to break anything else.

The way it works is that the developer of a new sub-system does the design on paper and brings it before the team for critique and discussion. The team is allowed to make suggestions and the author (designer) takes them away and brings the revised design back to the team for approval. In most cases, the original designer has final say about the suggestions the team makes, unless there's something particularly controversial, in which case it gets kicked up to a manager or team lead for a tie-breaker. This process is done before any significant code is written, since it's much easier to change diagrams and text than it is to change code. Whether your requirements for the design came from the ARD (Almighty Requirements Document) or a user story, doesn't really matter.

This process works really well. Most of the developers I know that use it, swear by it. Interestingly enough, although it resembles a "committee" (a dirty, dirty word), design reviews seem to happen without any large amounts of friction or politics and can be done without introducing significant delays in throughput. Developers are usually a pretty pragmatic bunch and genuinely do want to produce the best designs and code possible (they are on a never ending quest for the most elegant solution to a problem, regardless of who's idea it was). In almost all cases, I've seen the original designers take enough criticism to send your average person crying and happily go about adjusting their designs, ready to come back for another round. Everyone knows that the process is for the greater good, and developers usually love it when someone else spots a possible hole or problem that they missed (saves them work fixing it later!).

This is essentially a peer review process. It means that for design (which is critical), nothing gets implemented without the support of the team. It means that the whole team is aware of what's going on and gets a broader view of the entire application.

From a group dynamic perspective, another interesting thing to note is that instead of say, 9 developers pointed at their boss for approval, each of the 9 developers is looking to the other 8 (or some designated sub-set) for approval. That's what I call healthy peer pressure. Developers take pride in their designs and their code. Who wants to look dumb in front of their peers? Or sloppy? Who wants the team to think that one of them could have designed it better? When you know you're presenting your work to peers who are actually capable of critiquing you on a detailed level (versus presenting your work to a boss who's never coded or doesn't know the details of the implementation), you take great care before you step into the room, designs in hand.

What's really going on in the design review process (or code review, after the design is implemented but before the code is considered "complete"), is that the team is truly collaborating. They are discussing, critiquing and learning about parts of the system that they themselves are not directly on the hook for. Each sub-system gets the benefit of the whole team's knowledge, for not a lot of extra overhead. Mistakes are caught, risks avoided, conflicts resolved before the expensive (time and money) part begins - the coding.

I believe that there are many more "management" activities that can benefit from this dynamic, in software projects. What about reviewing time estimates as a team? Schedule? Priorities? Risks? Bugs?

I believe that having each person not only accountable to the "boss", but instead to each other, creates a whole new level of performance. We often like to speak rhetoric like, "we're a team and we depend on each other to be successful", but often don't act accordingly. Many of our processes still reflect a bunch of worker bees being held accountable by a single boss-like entity.

Take this peer review process far enough and it could beg the question, "Who's managing this project anyway?" Answer: the team.