Uncommon Sense (for Software)

New Feed URL for Uncommon Sense (for Software)

2006-11-30T16:03:00.000-05:00

I've hopped over to Typepad for my blogging needs. The Web URL is still the same:

www.UncommonSenseForSoftware.com

... because I've remapped the domain to point to Typepad. However, the RSS feed URL has changed to:

www.UncommonSenseForSoftware.com/index.rdf

Please update your feed readers with the new feed!

Happy trails,

Craig.

Last reminder that the blog has moved...

2006-04-24T11:32:00.000-05:00

Hi there,

Last call to let you know that this blog as moved to:
www.UncommonSenseForSoftware.com

Please update your bookmarks and feed reader.

Thanks!

Craig.

Outsourcing Development = Giving Away Your Success

2006-04-10T10:15:00.000-05:00

There's a new article over at the new location for this blog:

www.UncommonSenseForSoftware.com

If you haven't already, please update your feeds and bookmarks!

It's the details that separate us from the apes.

2006-04-03T22:05:00.000-05:00

There's a new article over at the new location for this blog:

www.UncommonSenseForSoftware.com

If you haven't already, please update your feeds and bookmarks!

Uncommon Sense (for Software) is moving...

2006-03-29T09:28:00.000-05:00

I've been double posting for a while now, here and at my new domain: www.UncommonSenseForSoftware.com.

I'll only be posting over there from this point forward. Please update your feeds and bookmarks!

My dreamPod

2006-03-28T09:17:00.000-05:00

My dreamPod
Originally uploaded by craig_in_ottawa.

So, I saw this funny video about DRM (Digital Rights Management; video by David Berlind at ZDNet). Damn, he makes a good point. I was really getting the itch to pick up a video iPod too. Guess I'll wait a bit. Afterall, unless consumers put pressure on vendors to open up, they'll stay proprietary - it's in their best interests.

Then, I got to thinking... The other problem with picking up a device like this is that 4 months later, I'm gonna wish I had waited for that one extra feature that the "next" version has.

What would I want in my dreamPod? Here it is (photo). Let me give you a tour...

1. Camera - facing away from the user. This is the one that let's you snap a quick photo while you're watching the LCD screen to make sure you've got everything "in frame".

2. Camera - facing the user. This one's used for the inevitable two-way video phone functionality, or for you to annotate a picture you just snapped, or to film you and your buddy/girlfriend standing in front of Niagra Falls.

3. Speaker - just enough for you to hear it with your ear pressed to it - because of course, this device is also a phone now.

4. KEYS button - one of my pet peeves with the otherwise brilliantly simple input design of the iPod is that you can't input the Contacts, Calendar or other typical PDA data that it's now starting to support. If you had a quick key for KEYBOARD, then you could just use the touch pad to zoom around the on-screen keyboard and press the center button to "press" a key. This I think would actually be better than a physical keyboard for text-messaging, and also better than a stylus and hand-writing recognition that doesn't work anyway.

5. MIC - Most phone mics are pretty good now. They don't need to be "exactly" where you put your mouth, just in the general area.

6. PIC button - 'cause for candid pics, you've gotta be quick!

7. Center button mod - let's make the touch sensitive surface include the whole circle (button included), not just the donut shape around the perimeter. This opens up a lot more input possibilities than just a "dial" experience.

Dare to dream. I think Apple could do it if they put their minds to it. Maybe they already are...

Tembria - Server monitoring for the rest of us.

2006-03-27T09:14:00.000-05:00

After finally moving the Devshop web-site to a real server in a real hosting facility (SAVVIS via LayeredTech), it was time to get some server monitoring software up and running. I want to know that my site is always up and for something to tap me on the shoulder immediately if it goes down.

My pet peeve about monitoring software is that it typically looks like it's been run over repeatedly by a mac truck. I mean it's so ugly I wouldn't kiss it with your lips. Difficult to use, far too much use of command lines and console output, the list goes on. There are a select group of real network admin experts out there who don't seem to mind these kinds of products. After all, form follows function, they would say.

Unfortunately for a lot of folks like me, we inherit the responsibility of making sure servers are up and running even though we are not as knowledgeable about this sort of thing as our network admin friends are.

So thankfully, there's Tembria. Tembria's server monitor not only has so many of the bells and whistles that our network admin friends would expect, but it's actually usable by non-experts like me.

Check out the screen shots.

More on the upcoming Ottawa BarCamp

2006-03-22T09:11:00.000-05:00

A location for the upcoming BarCamp Ottawa has been chosen: BitHeads at Carling and Merivale (Ottawa). Apparently the space is very swank. It used to be an old movie theatre, converted by the BitHead folks for just these kinds of events.

We've reached our sponsorship goal. Many local companies have pitched in to make this event happen. The list of attendees and sponsors can be found on the BarCamp Ottawa wiki.

We're still looking for more participants! If you're interested in leading a session on a cool topic, or just in coming along to participate, sign up on the wiki.

Hope to see you there!

Review of Devshop site

2006-03-17T21:20:00.000-05:00

Geof Harries over at YukonBiz has reviewed the new site and material we put up about the product.

He even throws in a Batman/Robin reference... Can I use that in my Marketing materials?

New Devshop site is up...

2006-03-17T13:31:00.000-05:00

The new Devshop site was put up at 2am this morning. Take a look!

Devshop

Death by a thousand cuts

2006-03-15T19:56:00.000-05:00

One of the biggest software project killer factors is requirements management - or more accurately, lack of requirements management. You've seen it: requirements that either keep growing, long after development has begun, or change more regularly than you could possibly keep track.

(I once worked for a company where the leadership team was still arguing about what the product was supposed to be, a month before it was supposed to be done.)

Everyone knows that requirements management is a problem. So if knowing is half the battle, then what's the other half? Why isn't there a well known, clear solution? What does it actually mean to "manage" requirements?

The trouble with most cases of changing requirements is two fold:

Each individual change is small enough to slide under the radar: If it only takes a developer 4 hours to knock off a new feature, where's the harm? So it's not tracked...

Since the changes aren't tracked (and tallied), the sum of the changes quietly adds up, but is never addressed in the schedule.

Before you know it, you're now 2 months behind schedule, and sliding fast. This is like death by a thousand cuts. A single paper-cut may be little more than a nuisance, but a thousand at once can make you bleed to death. I saw a movie once (can't remember what it was) where the bad guy was stealing money from a bank by hacking into their computers and collecting all of the fractions of a cent that resulted from certain bank transactions. Since it was fractions of a cent, it was virtually untraceable, except that over billions of transactions, it eventually added up.

Most people intuitively know that changing requirements mid-cycle is bad, but they don't realize how often it happens, or what the impact is, so they're powerless to adapt for it and schedule around it. Since they don't see the impact, they have no incentive or reason to knock it off. And in the end, it's not the changing requirements that kill us (adaptability = good), but the fact that we didn't plan for them or that we let them get out of control that does. It's the unwelcome surprise.

Managing requirements doesn't necessarily mean determining them all up front, before development begins, then freezing them through a development cycle, and saying no to every request until the thing ships. That's just not realistic. Adaptability afterall, is a key strength in business.

Well, if not that, then what? The first part of the solution is quantification. It's no use trying to use anecdotes to show people how "requirements keep changing and it's going to make us late." Chances are, the only examples you'll have at your finger tips are those "4 hour" requests that don't have the shock factor you're going to need illustrate your point. Remember, no single change request is the problem, it's the cumulative effect where dealing with. So if you can't demonstrate the cumulative effect, the message just comes off as complaining and falls on deaf ears. To show the cumulative effect, you need to have tracked them - all of them. That's the only way you'll have a shot at credibly demonstrating the impact. Each one may only be 4 hours, but x3 per week is a minimum of a 30% reduction in some poor developer's productivity, not even including the context switch (arguably another 20%). Then there's the fact that every seemingly 4 hour request actually balloons to a full day when all's said and done.

Suppose you've quantified the impact early on. Let's say, in the first 2 months of a 6 month project, you've calculated that requirements changes have added up to 2 weeks worth of extra effort. Not only are you now 2 weeks behind schedule, but if the trend continues, you're likely to add another 4 weeks of requirements change in the remaining 4 months of the schedule, for a total impact of 1.5 months of your original 6 month schedule. All for seemingly little requests here and there.

So managing requirements doesn't mean Big Up Front Design and no changes mid-cycle, it means:

Tracking and trending the changes

Using the trend to assess impact

Making good decisions around how much of this change you should plan for in your schedule

Only by tracking the seemingly harmless change requests can you see their cumulative effect before it's too late. Not letting them surprise you and catch you flat-footed is key. Only by using real data instead of anecdotes can you have productive conversations about requirements change with those that need to know.

BarCamp Ottawa Coming Soon

2006-03-09T08:43:00.000-05:00

I've offered to pitch in and help organize BarCamp Ottawa with Peter Childs, Alec Saunders and David Keys.

BarCamp is called an "unconference", which makes it very much cooler than just a conference, you know, without the un. Seriously, it's a way for us folks down in the trenches of Ottawa's high-tech to get together, meet eachother, swap stories and experiences, and discuss some topics that are near and dear to our own hearts.

Yesterday we had a meeting and the following theme suggestions came up:

Web 2.0 (obviously!)

Voice 2.0 (over IP)

Wi-fi

Extreme Programming

As BarCamps go though, it's not the organizers speaking and the attendees listening. It's very much the attendees as participants and speakers. If you've got a topic area you'd like to huddle on with some folks, head over to the Wiki and post it! Add yourself to the list of attendees if you can make it.

The date is Saturday, April 22nd, location TBD. It's totally casual, and free, but you have to participate! Spread the word!

Also check out:

The rules of BarCamp

Project Management Quotes

2006-03-08T07:20:00.000-05:00

Stephen Seay over at Project Steps posted a long list of project management quotes. Some of them are kind of funny and just a little cynical.

These are my favorites:

The sooner you begin coding the later you finish.

Good time estimators aren't modest: if it's huge they say so.

Everyone asks for a strong project manager - when they get him they don't want him.

The first 90% of a project takes 90% of the time the last 10% takes the other 90%.

If it wasn't for the 'last minute', nothing would get done.

If project content is allowed to change freely the rate of change will exceed the rate of progress.

The Power of the Suite

2006-03-02T23:15:00.000-05:00

A week or so ago, I was chatting with someone about what I often bash as the "one kind fits all" approach to project management. The idea being that different kinds of projects have different risks and challenges, and therefore, require different techniques to really nail them. Anyway, this person mentioned another "one fits all" phenomenon where he worked... The customer (internal users) and the development team of this organization kept wrestling with this "one application that does everything." Over time, it seemed that this one in-house application had become responsible for nearly every aspect of operations. In other words, they had tried to automate every aspect of their business, and as if that wasn't bad enough, they were trying to do it inside a single application. This is enterprise software at its worst.

This "one app that does it all" approach is dangerous for a couple reasons, both having to do with complexity. First, there's the complexity for the user - good luck training someone on something that has a zillion whirly-dos, what's-its and gizmos, and has completely lost any resemblance to the original metaphor that was supposed to intuitively convey how to use the thing in the first place - or worse, is nothing but 45 tabs across the top of your page, each with another 20 tabs below them (you know who you are!) Second, there's the complexity for the developers. The more business rules and features crammed into a single code-base, the harder it is to maintain, the slower it is to innovate with and long story short, the more expensive it becomes (serious diminishing returns with each added bell or whistle, or whirly-do or gizmo).

And then the pendulum started swinging back the other way... Over the last year in particular (ok, maybe starting 2 years ago) there has been a significant movement back towards simple, single purpose apps. For anyone claiming to have nearly invented this, they're just too young to remember that before applications got so big and complex, they were in fact much smaller and more simple (ahhhhh, the good ol' days). I really hope nobody labels themselves the "Grandfather" of simple, single purpose apps. I've read there's a Grandfather of AJAX, but, really? Did he invent or write the XMLHTTPRequest objects that have existed in browsers from different vendors for years? People love to have a hero. But that's another story. We just got carried away with ourselves for about a decade, us and our big ol' enterprise apps, that's all.

So here's the paradox: (or maybe conundrum, I’m not sure which): Bigger, more sophisticated enterprise apps will always win the feature battle. Some functions just require a lot more flexibility and programmability than small, lightweight tools can offer. These monsters will always be expensive and time consuming, but they serve some purpose - assuming they're not taken overboard with the "one app for all needs" approach.

On the other hand, I've never been a big believer that businesses in particular have needs that are soooooooo unique that they can't possibly find an off-the-shelf tool to do about 80% of what they're looking for and then get all those really smart employees to use their brains, arms and hands to do the other 20% - thus avoiding the pitfalls of never-ending-software altogether. But, that's just me. It's a good practice to always look around for the commercial tool that does most of what you want and be realistic that it may not be cost-effective to try and build something from scratch just to get the other 20%. If you're building your own timesheet software, stop it right now! Shame on you! Never mind the fact that delegating every single aspect of your operations to a computer program tends to tie the hands of your employees, especially in situations of customer service. How many times have you heard, "I'm sorry, the computer won't let me do that. I can't help you." Gee thanks. Hooray for progress.

So I guess you could say, I'm warm to the "simple, single purpose app" movement - with one caveat: At some point, when people max out their potential with a simple app, they inevitably want more. So how do you give them more, and still keep the app simple and follow a single design metaphor? This is the product life cycle challenge that forces so many companies who at one point early in their lives sang the virtues of simplicity, to change their tune to one of feature richness and customizability. In short, they grew up. And so they traded one set of challenges (not having as many features as the big guys) for a different set of challenges (not being as nimble and easy as the little guys). It’s kind of like a 16 year old complaining he’s not being given enough responsibility and then turning 35 and wishing he was 16 again without a care in the world.

Truth is, there's a happy, blissful middle ground: the product suite. See, with the suite, you get a handful of related, compatible, yet independent "simple, single purpose apps" that talk to each other. The benefits, they are a plenty:

Users get to dip their toe in the water by adopting one of the products in the suite without adopting everything at once and possibly being overwhelmed. They can grow with you and adopt other related tools as they need. Better still, they are motivated to use YOUR other tools instead of the competition’s, because yours are all integrated and that provides added value.

Individual products can stick to a single metaphor and be super easy to use, but gain some of the benefits of "big" software by relying on and exchanging with their brother and sister products.

Because the overall functionality of the suite has been split up among distinct products (something us techies call partitioning), complexity is reduced for the user and the development team, so everybody wins.

The only thing you're left with is the odd user saying, "I don't want 4 apps, I just want one." (lazy ;)), but with a good talking-to and maybe quoting a couple paragraphs from this blog entry, you can turn them around so they see the light. The one legitimate complaint I hear about having to use multiple apps, is having to log-in all over the place. Single sign-on is probably THE killer feature for a suite of products - don't forget it.

So, hooray for the movement back to simplicity in design - let's just not forget that sometimes people need more than one app can give, and let's get these apps talking to each other in meaningful ways instead of cramming everything into one box.

Happy trails.

Contact info...

2006-03-01T09:22:00.000-05:00

I've had a couple comments recently asking for contact info. You can reach me by email here.

Now you can send me all kinds of secret messages.

Presentation to Ottawa developer group

2006-02-23T08:49:00.000-05:00

Last night I had the opportunity to present my company (Devshop) to a group of local Ottawa developers. Devshop is currently developing a radical new web-based project management tool specifically designed for software teams to address the common challenges associated with software projects. More on that coming soon. The forum was a monthly OGRE meeting (Ottawa Group of Ruby Enthusiasts), hosted by the team at JadedPixel.

I know at least a few of the folks at the meeting last night will be checking out this blog, so to you, thanks for the opportunity to present and the brews shared at the pub afterwards. Good times.

Devshop has been in stealth mode for some time now. In the next couple of months, I'll be free to start letting the cat out of the bag (at least up to its ears & eyebrows). The first real web-site explaining the goals and the product (and most importantly, what it means to software developers of the world) is in progress and will be up in the next few weeks. Hope you'll come back for a visit to check it out.

Many thanks to everyone that attended last night. 'Be seeing you.

Design a couple versions at a time

2006-02-16T08:13:00.000-05:00

Every day in the software world, you run into people that rather neatly fall into 2 camps:

Design snobs

Those that think design is icing on the cake

I personally am in the design snob category. I believe that design (or lack of) makes or breaks a product. A lot of times, I'm talking just about user interface design, but the truth is, anything said about user interface design can typically be applied equally well to technical design. The technical equivalent of user interface design, for a coder, is the design of their public interfaces - the methods and properties you can call on their class library.

In both cases, there is always a tension for designer between "what would make it easier to implement" and "what would make it easier for the end-user". This is equally true whether the end user is someone clicking a button on the user interface, or another developer trying to use your API. Either way, the designer's #1 job is to empathise with the end-user. The biggest danger a designer faces (interface or technical) is to start thinking too much about implementation too early. Design is an expression of the end-goal. Start with "here's what we want to get to". Even if you aren't able to get there in a single release, or have to make some tradeoffs along the way, start with the best design you can come up with, and work backwards to what is feasible given your constraints. That way, with your user interface or your technical architecture, you'll be able to come back later to fit things in that didn't make it in the first go-round.

If you design only what you think you can accomplish right now, you're going to have to bend and twist your design in unnatural ways in the next iteration, to account for things that you didn't account for in the original design. In short, over-design up front - do a couple versions at once. This thinking might throw a few folks into a panic because we've all heard from our ancestors that back-in-the-day large software systems experienced "paralysis by analysis", meaning, they never got off the drawing-board. That was before the 'Net. Given how easy it is to publish and distribute an application nowadays, people are slapping them together and shoveling them out the door with comparably little design (not to mention testing). Don't worry about over-designing.

If you spend about twice as much time designing as the next guy, you're probably spending just the right amount of time and your product will show it.

Plan for a couple of iterations, so you know where you're headed. Then you can break up the implementation of that design over a couple of iterations or releases. Since ripping up a design document is way easier than ripping out a chunk of code, it's better to design a few iterations at a time, so that if in iteration #2 you realize something in iteration #1 was going to create a conflict, you've caught it before it was actually implemented. The more we design a couple iterations at a time, the less products come out looking like Frankenstein later.

And just for the heck of it, here's a link to some great "importance of design" quotes I stumbled across, at LUKEW Interface Designs.

A couple of my favorites:

[Users] make their credibility-based decisions about the people or organization behind the site based upon the site's overall visual appeal.
- Stanford Persuasive Technology Lab, 2002

Design is not just what it looks like and feels like. Design is how it works.
- Steve Jobs, 2003

Visual appearance is one of the most effective variables for quickly differentiating one application from another.
- Bob Baxley, 2003

If a site is perfectly usable but it lacks an elegant and appropriate design style, it will fail.
- Curt Cloninger, 2001

The details are not the details. They make the design.
- Charles Eames

Problems with visual design can turn users off so quickly that they never discover all the smart choices you made with navigation or interaction design.
- Jesse James Garrett, 2002

Good design is the most important way to differentiate ourselves from our competitors.
- Samsung CEO Yun Jong Yong, 2004

Design is the easiest way to reenergize a product.
- Fast Company, 2005

Your products run for election every day and good design is critical to winning the campaign.
- Procter & Gamble CEO A.G. Lafley, 2005

You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.
- Steve Jobs, 2005

In Software Project Management, Size Doesn't Matter

2006-02-10T08:48:00.000-05:00

A few months ago, I was discussing project management with someone from the financial sector. This person, who is rather good at his own line of work, admitted he didn't know much about project management (but had some clients that did). We were talking about some new ways of looking at project management, particularly, the domain specific approach that I often advocate. Wanting to test my theories, he picked up the phone and proceeded to call one of his clients, whom he knew to be a real top-notch expert in project management. What is interesting is that this project manager client of his was perceived to be an expert not because of any particularly extraordinary skills he had displayed, or even a long list of stellar accomplishments but rather, because he managed really BIG projects - like 4 years, 200 people, $50 million projects. Big ones.

At first, I didn't even think twice. Of course, I thought, I suppose you would have to be really good to handle those kinds of projects. I mean, if co-ordinating 10 people is tough, 200 must be about 20 times tougher. A lot of people would certainly reason this way. After meeting this manager, which was a rather familiar experience (nothing much new), it triggered a line of thinking:

It is often far more difficult to manage a 10 person project than a 200 person project.

Let me explain. It's not that I'm saying that the person managing the 10 person team is more important that the person managing 200 people on a $50 million project. I'm not equating difficulty with importance - and by difficulty, I'm talking about the project management responsibilities, not other duties they may have to perform.

Speaking with this project manager in particular gave me deja vu. It was more like speaking with a CEO than a project manager.

In chatting with any "project manager" with a team size of 100 or so people, what you quickly realize is that they're not project managing anymore at all. They're more like a CEO, involved at the capital allocation level, for multi-year operations. They are running an organization. They're tuned in to major technological shifts and trends, like "If we bet the farm on Lotus Notes, will it still be the platform of choice when we finish in 4 years?" Heh heh. Oops. When you're talking about a project that big, the head honcho is managing managers, who possibly manage other managers, who have team leads, who lead the people actually producing the work. They are more like mentors to the managers who are actually managing. The organization is large enough then, that it becomes really difficult to see the direct impact that the top decision maker is having on the success or failure of the project. I liken it to riding (or steering) the wave, rather than causing it directly. How many debates have you heard after some political or fortune 500 scandal where hoards of people say things like, "Well, you can't blame the top dog for something that some underling in another office did. It's not his fault." There you have it, by popular opinion, less direct accountability for large teams. If you can't blame the top dog for failures, then how can you attribute success to him?

Life in a small team however (say 10 people), is much more likely to give you a heart attack. There's nowhere to hide. The pace is way faster. It's very easy to see the direct impact (good or bad) that each person is having on a daily basis. When you're managing a software team of less than 10 people, chances are, you're not just the manager, but one of the developers as well (or at least a designer or architect). The dynamic of a 10 person software team is much more clear - one person managing, and 9 people producing. I think it's at about 10 to 15 people, where it is no longer practical for a manager to even touch the source code - in fact, it can be down right dangerous. Coding is not something you should dabble in. Either let it consume you and be really good at it, or don't touch it. After 15 or more team members, it's quite likely that there will be a lot more delegation. At 15, you may have 1 manager and 1 technical team lead. At 35, you probably have a Director or a couple managers and a couple technical team leads. At 100, well, you get the picture. With each round of delegation (which IS necessary by the way), some amount of pressure, and direct accountability is taken away from the top dog. I'm not just theorizing here, I've actually experienced it. While I haven't managed a 100 person team yet, I can already see the difference between 10 and 35 developers, team sizes I have managed. To manage 35 developers you really need to break them up into teams of 5 to 7, with technical team leads, and a manager or two. So even at 35, there's a couple degrees of separation between the top policy maker, and the folks actually producing code.

In that awkward team size of about 10 developers, you're likely to be as much a producer as a manager. It's really tough to be great at both. Just like you shouldn't dabble at coding, dabbling at managing just makes you a manager with a disadvantage. It's at the point in time where it is clear to everyone around you that it is no longer practical for you do be doing any producing, but that you should be managing full time, that your project management life actually starts to get a bit easier. At that point in time where you have managers reporting to you, your project management worries get lighter still (though you probably have new responsibilities keeping you up nights).

All this to say, over that last 13 years of managing software teams, I haven't seen convincing evidence that project management difficulty increases linearly with team size. There's a breaking point at which the project management (only) difficulty actually decreases when the team sizes breaks a certain point. Project management worries then get replaced by other worries (like what the heck should we be betting the farm on... 'cause if I'm wrong, we go out of business - easy stuff like that).

Am I right?

Software Ideals.

2006-01-17T09:02:00.000-05:00

How many times in your life have you ever thought to yourself, "I'll just slap this together now, and fix it later." I'm not sure what it is about the brain's wiring that makes us think that somehow tomorrow we'll be much less busy, have much more money and more energy to do the things that we either don't have the energy for today, don't have the money for, or just don't want to do. Only in hind-sight, and apparently after quite a bit of experience do you learn it's just not true. Every day I wake up, there seems to be even more to do, with less money, and it's needed faster than ever - not the other way around. So in reality, that "tomorrow" we’re thinking about (the one with all the extra time, energy and money) never comes. So things never get fixed/patched/improved like we thought they would. After a long while, you look back at your work and realize all you've done was produce half-assed work always thinking you'd fix it "tomorrow". And here we were thinking we were just making those tough decisions, the compromises, to live to fight another day.

This realization begs a change in behavior. If in fact tomorrow isn't going to be any easier than today (and you're actually going to realize there are 5 more things you need to do on top of your current to-do list), then there's no time like the present to patch that hole, fix that bug, or do those sit-ups that you aren't going to feel like doing tomorrow any more than you feel like doing today.

"There's no time like the present." "Do it right the first time." "Anything worth doing is worth doing right." "Good enough, isn't." "Relentless improvement." "Whatever you're doing, do it better than the next guy." "Do a smaller number of things, but do them better."

These are phrases that have been rolling around in my brain for a while now. Over the last year I've been building a software project management application that will be released this year (not a small endeavor). My company's mission (Devshop.com) is to help teams produce better software. During this time, I've had a chance to re-evaluate many of the patterns and habits I've developed (and witnessed) over the years, in producing software for the companies I've worked for. One of the great things about striking out on your own is that you get to chose how you're going to "follow" the good patterns, and how you're going to break the mold and do things differently ("lead the pack").

We all know that no matter what we're doing, there's always going to be some kind of time pressure on us. I personally have always placed extra emphasis on not only getting a job done, but hitting your target date as well. In truth, looking back I've made some of those common decisions (mistakes) like cutting testing, cutting documentation, cutting user interface design all to hit what seems like a fairly arbitrary deadline, so that we can say we made the release date.

It just doesn't make good business sense. Not that you should keep your application in development forever until it's perfect – we've all heard the stories about applications that never got off the drawing board. But I'm assuming you have a set of reasonably fixed requirements. Those stories about applications that never saw the light of day got that way because of never-ending requirements change – not because some perfectionist didn’t want to release their code because it wasn't perfect yet. So that's really a different issue.

I think that the moral of that old story, "We need to ship at some point otherwise the software will never get off the drawing board" is out-dated. For the last 10 years at least, the trend has been to release software far too early (with not enough testing, refinement and design) rather than after too much fine tuning. Look at the state of software today. It's buggy. Slapped together. Rushed. Do not fear taking the extra time to get it right – fear shipping sloppy products. There's enough evidence out there that the "first mover" advantage is a myth. Too many times a "fast follower" has come along with a better implementation and kicked the inventor's butt with his own invention. All you accomplish by shipping a pre-mature product with a great idea is give the idea away to your competition at a time when you have a poor implementation of it - a bad idea. Getting the customer "first" is really important when it's nearly impossible to get them to switch later - but switching software is easy. Focus on keeping them once you get them, rather than just getting them first.

I've heard it said that the development phase of a product's life cycle is a small one-time cost (say, for one particular release), whereas support and maintenance is a large recurring cost. It's true. If you look at established software companies, their product development expenses are often far less than any other department – marketing, sales, support, operations... That's one of the great things about the software biz. If done right, you can spend (relatively) a little to build a great product, then sell it a billion times and make a pile of money. At least that's what everyone is aiming for. But notice I said "great" product. That's the hard part.

"Great" products aren't rushed, slapped together, ill-designed or buggy. They are the result of a steadfast belief that quality comes first. Not just quality only in the quantitative bug-count sort of way, but in terms of design, user experience and ability to solve the original problem. Great products aren't just a bag of features or a brochure as long as your arm. They are an "elegant" solution to a problem.

I think that we as software producers need to stop deluding ourselves that we'll fix it tomorrow, or that hitting a release date is the #1 goal of a software team. Tomorrow will never come (at least the tomorrow we're thinking about) and a timeline-over-quality approach leads to weak products.

I was recently faced with a business decision about when to launch my own product, and with what feature set. The choice was to launch sooner (a Quarter at least) with a much reduced feature set (that solved the problem "less well" than the original design) or to stay the course and deliver on the original mission. Giving up short-term revenue is not an easy choice to make for anyone. But ultimately I believe that it's the substantially better product that is going to win, not hitting the market 3 to 5 months sooner.

This decision has caused me adopt different habits. Like, when you find a bug, stop what you're doing and fix it now. It won't be easier or cheaper to fix later – it'll be harder and more expensive (time and money), when you've lopped another 20% of code on top of your application – or after it hits the street and starts affecting customers. My personal commitment, is to ship with "zero known bugs". Not that I and my customers won't find some after release, like with any software product, but I'm not going to use a "known issues" list as a crutch to ship early.

The need to stick to your ideals and put quality first is even more important for small companies. Maybe if you have a monopoly you can get away with bad customer service and poor quality products, because customers have nowhere else to go. But if you're an up-and-comer looking for an angle to compete on, make it quality. It's something that people sacrifice far too often and can give you a leg-up.

A Quick Recap

2005-12-13T09:11:00.000-05:00

My brain will soon be in holiday mode so rather than a whole article this week, we get a "flashback episode" of sorts.

I started this Blog in September 2005 just to give it a whirl. So far, over 2,000 unique visitors have stopped by and the list is growing. A few of you even keep coming back, so thank-you for that.

I believe very strongly that the way we all produce software needs some work. I believe that we as an industry need to get better at predicting when we'll ship our products and without falling back on sacrificing quality to hit some arbitrary date just so that we can say we hit the date.

I also believe very strongly that the general purpose project management approach doesn't cut it for software projects, which are by nature extremely complex. We need to focus on the things that are tripping us up specifically in software projects if we're going to crack this nut.

Here are some past articles in case you haven't seen them yet. Also, check out Devshop.com and put your e-mail address on file if you'd like to be notified when my product ships in the new year.

See you in 2006!

Craig.

Past articles:

Trick Question: Could You Manage a Space Shuttle Launch? This one is about how we intuitively know that domain specific experience counts, but haven't quite built that into project management methodology yet.

Customers don't buy "solutions", they buy products and services. May the best products and services win. Some thoughts contradicting the "solution selling" style. It's not for everyone.

If you get 1 thing right in your application, make it the User Interface. The importance of "look and feel" to your customers and your revenue.

More General Purpose Project Management Theology Isn't Helping Matters! A mild rant.

Keeping it simple. A point about focusing on the right things and forgetting the noise.

The Cost of Late Software. Do you know how much this costs your company? It's big.

Building Front-to-Back The benefits you can achieve by building your User Interface and getting approval on it before building out the back-end.

How to Explain Good Architecture to the Non-techie. It's more about operational effectiveness than anything.

A Trend Can Kill You. Hiccups aren't usually one-offs. They can often indicate trends you should be watching.

The Software Wasn't Late, It Was Supposed to Take That Long. The difference between really "late" software, and software that was estimated wrong.

The Power of Suggestion. A word about the denial that many of us live in with respect to software development.

Raising your Credibility

2005-11-23T16:34:00.000-05:00

As a project manager of a software project, one of your biggest responsibilities and greatest challenges will be to make people understand things they don't want to understand and believe things they don't want to believe. You will be fighting a kind of self-hypnosis, where people believe what they want to believe because it's just easier that way. (See also: The Power of Suggestion) This is the hardest kind of convincing. In order to pull it off, you're going to need to have a lot of credibility saved up. Credibility is like money - you earn it today so you can spend it tomorrow. Like with money, you can do things to invest in your credibility that will have bigger credibility payoffs later (a kind of Return on Investment). And of course, nothing builds credibility like a solid track record of delivery. It’s hard to argue with results.

Here are the kinds of beliefs you will have to dispel before you can get your various messages through:

"Other Co. is pumping out products at twice this rate, why can't we?"

"The development department has a pool table, so they aren't working hard enough."

"The developers all wear jeans and rock T-shirts so they don't take their work as seriously as the rest of us."

"Nothing else the company does takes as long as the software does, so something must be wrong with the way we develop."

"If we ship it now, we can fix the architecture later."

“We can’t just freeze all of the requirements for the next 8 months while we build the software. We need to be responsive to the market.”

Here's the strangest factor you’ll be battling: The very people that claim development takes way too long and is always late are the very people that will try to beat you up to lower your time estimates and cut any buffer time you put into the schedule (and thus jeopardize the project’s chance of success). Some of your stakeholders will be Sales people – professional negotiators. When they convince you to strip your buffers from the schedule and lower your time estimates, they believe they’ve won something. Go figure.

One approach to dispelling these development myths would be to arm you with various well written explanations and superbly logical arguments as to why they are false. In my experience, that doesn’t work. The truth is the very nature of software development starts you off with a negative credibility balance:

The net productivity difference (all-in) between a good developer and an average one can be as much as 10 times (various organizations have studied this), so attracting the “good” ones is very important

Attracting and retaining good developers is a highly competitive business, so perks like a casual (comfortable) work environment, good pay, stock options and flexible work hours are thrown in to sweeten the deal

Developers typically love their jobs, so even when the pressure mounts, they may not show the stress cracks as much as someone who is equally pressured but doesn’t love their job quite as much

Add to the mix the fact that most development projects (even some of your own) have been late or troubled, and you don’t have a lot of credibility to begin with. Because of these software development realities, you as a leader need to be on top of your game to counter the negative perception of the nature of software development. If you want to convince one of your stakeholders of something unintuitive, you need to be the pinnacle of professionalism with credibility to boot.

Here are the things I’ve found that build credibility and help you get your message through without falling into the trap of arguing about how hard the developers work, whether or not shirts and ties make you more professional or why attracting and retaining top-notch developers is in the company’s best interest, compared to another type of employee:

You need to deliver. You need to keep your word. When you say you’re going to be done in 6 months, it is critical that you are. If you succeed, the next time you need to convince someone of something counter-intuitive, you’ll have more credibility in the bank, so it will be easier. If you fail, the next time will be even harder. It’s a cumulative thing. Each success or failure affects your credibility balance.

In order to deliver, you need to protect your schedules. I call it Risk Management and it’s your #1 job as a software project manager. Since statistically most software projects fail (70%), you’re inherently on the defensive anyway, so you need to think like everything is a possible risk. One of the best techniques you can use to protect the schedule is to build-in time for all of the things that typically throw software projects off the rails. Things like: Time Estimation Error, Distraction Rates, Overhead, Requirements Churn, etc.

In order to protect your schedule and the “padding” you’ve put in, you’re going to need a solid rationale as to why that particular % of time was chosen, and what factors you’re padding for. Otherwise, when you go up against a professional negotiator (like a Sales person), you’re going to walk away having been talked out of your padding. And while simply “refusing to give in” is better at protecting the schedule than giving-in, being able to convincingly articulate what you’ve padded for and why you chose the amounts you did is even better. It protects the schedule and builds your credibility at the same time.

Never use your “gut” as an unsubstantiated argument. You can talk about how good your instincts were after-the-fact, but it’s not very convincing up-front unless you already have a huge credibility balance. While I’m a big believer in using your instincts as one of the data points in decision making, it’s best to figure out a way to prove or disprove them anyway. If you disprove a gut instinct, you save yourself a costly mistake. If you prove it, you gain more credibility anyway, so it’s a win-win.

Be an obsessive note taker. Most people don’t do this. It takes discipline to get in the habit. In the moment, it’s hard to know which decisions or facts you’re going to need as corroborating evidence later, so write them all down. Any time you can point to written historical evidence of decisions that were made, when, and by whom, you’re going to have a psychological advantage in getting your point across. People regularly (and conveniently) forget how often they’ve changed their minds on their priorities, or a feature list.

Use metrics. Figure out what metrics you think are important for your type of project and track them. Whether it’s the rate of change for requirements, or how often time estimates are wrong (and you are therefore padding for that fact), nothing backs up padding in the schedule like stats. It’s hard to argue that a 30% buffer in the schedule is too much when you can point to statistical proof that developer time estimates are off by 30% on average, over time.

Hopefully some of these tips will help you incrementally increase your credibility balances. Unfortunately there’s no overnight solution, but with discipline and a structured approach, you can do it.

If anyone has any other tips or tricks on the subject, I’d love to hear about them. Please post a comment.

Trick Question: Could You Manage a Space Shuttle Launch?

2005-11-14T10:46:00.000-05:00

A few months ago I spent a couple hours with a project manager who by all accounts, is rather good at her job (I know several people that know her professionally and did some background checking). We were discussing domain (software) specific project management techniques, like tracking Time Estimation Error, Distraction Rates, and keeping requirements in-sync with schedule. As our meeting was ending, she mentioned that someone had asked her a while ago whether or not a good project manager (or a project manager with a good project management methodology) could manage any type of project – like a space shuttle launch. She quickly said yes, because the basic elements are the same in any project. It occurred to me on the drive home that this is not an uncommon belief – that a project is a project is a project...

So – why we are we (the project management discipline at large) so terrible at running software projects specifically? It’s a well known fact that the majority of software projects globally are considered failures (Standish Group’s Chaos Report) – failure being defined as: late, off-spec, and/or over budget. If general purpose project management methodologies aren’t making software projects slam dunks, then either the methodology isn’t all it’s cracked up to be, or there’s something about software projects in particular that continues to trip us up. I say both.

Here’s a trick question. I will read all sorts of things into your answer to this question and tell you about them in a minute: If you were the head of NASA, responsible for choosing the project manager for the next space shuttle launch, and you had 3 candidates to choose from, which would you choose? Here are the candidates:

“Newbie PM (Project Manager)” – has accreditation from a leading project management school; graduated top of class; knows the PMBOK (Project Management Body of Knowledge) like nobody’s business; can quote the process to you word for word; never managed a project.

“General purpose PM” – has accreditation, and has 10 years experience managing all sorts of projects (but never any 2 of the same type); sample projects ranged from: building a new home, a Windows 2003 server rollout, a training program for a new software system in an organization with 10,000 employees, planning a sales conference, etc.

“NASA veteran PM” – has accreditation, 2 years experience managing a variety of projects (similar to candidate #2), but has been managing space shuttle launches for the last 6 years.

Which would you choose? You’d probably want to know their track record too, but for the purpose of this little game, that information is not available. I’d bet dollars to donuts you’d pick #3 – the NASA veteran. But if you also started this article thinking that with a good process you can manage any type of project, then something is at odds – those 2 opinions are inconsistent with each other. If you truly believed that the process was the key, then technically any of those 3 candidates should do fine, because they all have the process down pat (the accreditation). And candidate #2 actually has more years experience overall. Reading between the lines, here’s what I think is going on:

Managing isn’t a true/false binary thing. Of course you can manage any project with any project management methodology, but the real question is: what would your success rate be? If you chose candidate #3, it’s because your instincts told you that experience with that particular type of project (a space shuttle launch) counts for a lot. Most people would intuitively believe that candidate #3 has something above and beyond the other 2 candidates.

Most project management methodologies are general purpose. For whatever reason, they continue to embody the opinion that all projects are the same – and should be managed the same. They are specifically designed to take the human element out of the equation – to say that anyone following the process can manage a project well – it’s the process that counts. For software projects en-mass, this approach clearly isn’t working, as evidenced by the poor success rates.

Today’s project management methodologies are useful for teaching someone the ABC’s of project management. There certainly is a lot of useful stuff to be learned. Unfortunately, there’s also a lot missing. Just like in school, consider that the typical project management accreditation is like a Bachelor’s degree. And we all know how dazzled prospective employers are when we tell them that we have a Bachelor’s degree right? Well, maybe not so much. Current project management methodology is the scholastic equivalent of reading and writing. You may need it, but you only learn the good stuff after you learn to read and write.

The real power (of success) – the advanced stuff - comes from some degree of specialization. If you want to go beyond the basics of project management, and hike up your success rate, you’ve got to focus on a particular type of project. Most of us do at some point in our careers anyway, because the organizations we work for are somewhat specialized: IT, Construction, Legal, whatever. What isn’t typically specialized however, is the methodology we use to manage those different types of projects. Our organizations specialize in some type of business, we specialize in some kind of project, and then we go use a general purpose methodology – no wonder software projects are late most of the time.

Specializing a project management methodology simply means looking for factors that typically affect a certain type of project (example: software projects), and modifying the methodology to account for those factors. (This is another way of saying: leveraging domain specific experience.) For software projects, some of the top factors that throw them off the rails are:

Time estimates are wrong – granted it’s difficult to produce accurate estimates, but few actually try anything more scientific than gut feel estimates, so we haven’t quite exhausted the possibilities here.

Distraction is rampant – software projects are long term (6 to 12 months) by nature, and are planned to have teams work on them near full-time, but the actual amount of time they get to spend on them is typically far less than near full-time; such is the nature of business.

Requirements consistently fall out-of-sync with schedules – we’ve somehow convinced ourselves that we can continue to evolve requirements and designs all the way through the project, but somehow the initial (gut feel) time estimate should stick.

If we know that these are the biggest common factors that throw a particular type of project off the rails, then what have we done to our methodology to account for them? Not much. Typically, most project managers of software projects are still trying to get away with that plain vanilla (“goes with everything”) project management methodology. It’s never going to work. It’s only half the solution.

Veteran project managers that have a high success rate typically use domain specific tips and best practices to run their projects. They’ve developed their own checks and balances to alert them when something is sliding off track. They’ve learned over the years, what the common factors influencing their particular type of projects are, and how to manage them effectively. Mostly, they do it in their head – they rely on experience and intuition to side-step the common pitfalls. For example, a veteran software project manager keeps tight control over requirements and schedule – keeping them constantly synchronized. He or she knows enough to take developer time estimates and pad the heck out of them, because there is typically an error margin with them. He or she also knows that on any v2 of some project, there had better be some time built in to fix bugs from v1, based on experience.

It stands to reason that these domain specific habits of the successful veterans would be of tremendous value to all other project managers in that particular domain. The trouble is, currently, it takes years to develop that experience and success rate. Wouldn’t it be great if this stuff was sharable, given to each newbie project manager in a particular field, and more widely and explicitly adopted? I think it would have a dramatic impact on the software industry’s track record as a whole. In fact, wouldn’t it be great if that acumen, those tips, tricks and experiences were built into your project management tool so that tracking, trending and reporting on all of it was automatic?! (Blatant plug: My company[Devshop.com], still in stealth mode, is working on a solution to this very problem – stay tuned!)

If you want to improve your success rate with project management, specialize. If you’re taking on projects of similar types (all software projects for example), don’t automatically look to more accreditation or general purpose PM methodology for the answer. First look for the patterns that throw your particular type of project off the rails, and manage those factors first.

Customers don't buy "solutions", they buy products and services. May the best products and services win.

2005-11-02T19:58:00.000-05:00

Several years ago, I remember being enlightened by some Marketing folks about "solution selling". The idea is that there are some strong advantages to elevating the discussion with prospects from simple feature lists and head-on comparisons with other products, to the broader topic of which "solution" is better than the other "solutions". See, a "solution" is fuzzy concept. It's really hard to quantify a solution, or say with certainty that one solution is better than another solution. Unlike feature lists. With feature list comparisons, one product typically comes out quantifiably ahead. Not good if yours is the weaker product. And so for many companies, solution selling became a great way of taking attention away from the feature lists (where they didn't look so good) and also made them feel like they were taking the high road. "Oh, Mr. Customer, feature lists aren't important. Look over here."

Over the years, I allowed myself to be convinced of this tidbit. After many years of working in the enterprise software space, I've come full circle and no longer believe it. Customers don't buy solutions. They buy products and services. The reason they buy products and services instead of solutions is that in the buying cycle, they typically only hook up with a prospective vendor after they've gone through the first few steps:

Feeling the pain of some problem

Understanding what that problem is in broad strokes

Looking around to get at least a light understanding of what some of the categorical solutions may be

Choosing the most suitable "category" of solutions

Begin researching products and services in that category

For example: If I have the problem of not being able to get everywhere I need to go with the two legs I was given at birth, then I don't start looking around for a "transportation solution". I already know enough about the various categories of transportation options (bikes, cars, buses, motorcycles) to weigh the various pros and cons of each, without ever talking to a vendor. If I settle on the idea of a car, then a bike vendor is going to have a real tough time convincing me I should go with a bike instead of a car. But, I've still got several car vendors and products (and services) to choose from, so there the selling game begins. Either I approach a handful of vendors on my own, or they "pull" me in with various advertisements, cold calls and free x-boxes with the purchase of every new vehicle. By that time, I'm a qualified lead. I'm not so much looking for a conceptual "solution" to my transportation problem, I've already narrowed it down and I'm now looking for a product or service with which I can solve my own problem.

Sales people know that it is way too costly and difficult to "create" demand. They land more sales and get bigger commissions by seeking out prospects that already have demand, and have determined what kind of "solution" they need. They are now at the product (or service) comparison stage. Now it's your product vs. the other guy's.

Besides. If a legitimate business problem is "we can't keep track of each time we interact with a customer", then most businesses figure out on their own that a CRM system is a categorical solution, and then enter the product comparison stage all by their lonesome, without the CRM company having to do too much to convince them that they actually need to keep track of all their customer interactions in the first place. And as further proof, I submit to you: When's the last time you saw a contract or invoice that read: "Ability to keep track of all customer interactions = $50,000". No, but many read:

Server license: $10,000

User licenses: $30,000

End-user training: $5,000

Telephone support: $5,000

There we go. They bought products and services. Not a solution. It's the things that appear on the invoice and in the contract that they actually bought. Not what problem they intend to solve with those things.

The reason this is significant is because it informs some strategic decisions for software companies. If you're selling a "solution", you're probably one of those companies that doesn't put a feature list, sticker price, or screen shots of your product on your web-site because you feel it cheapens you. You expect prospects to call you to ask to get a demo from sales rep that's going to hound them until they either buy or tell them to bugger off. I can tell you from experience, droves of possible customers will turn away without going past your front page if there aren't clear links to some or all of those things prominently displayed on page 1. The reason is, they don't need you to tell them what their problem is or what the solution is. Rightly or wrongly, they already believe they know, and now just want to easily compare your product (or service) to someone else's. I really can't see why hiding important information like that is a smart move.

In the last year I've gone looking through several product categories: Project Management software, Content Management software and Web-site Tracking software to name a few. Those companies that thought they were selling me a "solution" to "knowing my Web-site visitors", "creating predictability for my projects", or "consistent customer service" and hid their key feature lists, screen shots and price from me, didn't get more than 5 seconds of my attention. I don't have time to call a sales rep for each of the 20 products I want to have a peak at. Nor do I want to give you permission to keep emailing me or calling me just because I asked you how much your product was or if I could see some screen shots. If all of that kind of information is hidden, then I proceed to assume: it's too expensive, too hard to get started, and I generally won't like the product.

All this to say, put the focus where the customer is going to put it. On the product. What does it do? How does it do it? Is it easy to use? How much does it cost? What's better about it than the competing products? The one exception to this rule is if you're in a space that is so entirely new that consumers in general haven't even figured out that they have a problem yet, or what any possible solution may be. In which case, you've got a lot of education to do before you can sell anything, and I don't envy you.

It's not that I'm advocating your message and materials should only consist of a price and feature list for comparison shoppers. But somewhere in between the two extremes of completely abstract solution selling, and totally comoditized selling of a bag of features, lies a happy medium, where the focus is still on the products that solve the problem. Being "product" (or service) focused with your messaging doesn't just mean you're a list of features and nothing more. In fact, many times, products with less features are better than their bloated competition. The magic is how those features (I prefer capabilities to features) are sewn together in ways that are more useful, valuable or easier to use than the competition. Those things translate into competitive edge.

The funny thing is, I hear from several Marketing folks as they flip through product web-sites, particular technology companies' sites, a snort of contempt: "They're all so product and feature focused. They don't understand solution selling. They need to elevate the discussion." Actually, I think they just know their audience and want to make it real easy for them to make a qualified decision. If your product is weak, then invest in making it stronger - don't go hiding it from plain site behind a lot of abstract "solution" talk. Stand by your product, and at the end of the day, may the best products win.

If you get 1 thing right in your application, make it the User Interface

2005-10-28T19:16:00.000-05:00

Here's a train of thought that further proves to me that a good User Interface can make or break an application.

The thinking goes like this... To be really successful, a great strategy is to do a smaller number of things, but do them noticeably better than the next guy. In other words, don't spread yourself too thin. Nobody ever became fabulously successful by doing a long list of things in a mediocre way. If you want to get noticed, you've got to do something worthy of notice, something that most other people stop short of doing (because it's too hard, or takes too much investment for them to do). You need to take something to the next level. That's what gets you noticed and gets people talking. That buzz creates momentum and can bring all sorts of good things (reputation included) your way.

If you want to do something really well, a good place to start is figuring out what "well" means. By what factors will your task be measured? And exactly who will do the measuring? Knowing what buttons you need to push, and who owns those buttons is a tremendous advantage. It helps you plan your game - how you're going to go get that high score in the right people's eyes. It's worth a few minutes, days even, to make these things explicit. Think about them. Write them down. Once you've got a handle on those things, choices about how you're going to spend your time, what pieces of the overall puzzle you're going to invest your energy in become a lot easier to make. You can make wiser decisions. For example, the Dot-com bust taught a bunch of people that there's no point in investing heavily in getting "clicks" or "eyeballs" if you're ultimately going to be measured only by actual sales. Oops, a bunch of people were measuring themselves on the wrong scale.

Now to apply this to software products... What buttons do you need to push to make a software product successful? When you hear high-flying CEO's being asked about what made their companies successful, I've never heard, "Well we have 47 features and the competition only has 40, so we're more value for the money." Rather, you'll hear things like, "We're the ones who made it really simple to do X." Making a software product simple is all about the User Interface.

In software, who's going to score the product? Not your boss. Maybe not even the person that "purchased" the software (on behalf of an organization full of end-users), but the actual end-users themselves. They are the ones that are going to love or hate your product and determine the level of repeat business and referrals you get - or don't get.

That being the case, it's a shame that most User Interface work is tacked onto the end of a project like a necessary evil. (And we all know that things left to the end of a software project are the first ones to get cut.) Seems to me that people have it backwards. Do the most important things first. Make them absolutely shine before you spend your time doing anything else. Because if you haven't got those things right, nothing else matters. If that means you had to cut some features, but shipped the features you did finish in a product with a User Interface that is really strong, you'll be far better off - in the eyes of the people who matter most: the people holding those buttons you've got to push - the users.

I don't know a single software company or team that wants to deliver a piece of software to their customer and never get repeat business. What that means is that the end-goal isn't just getting the contract signed off or getting paid "this time". It's about creating fans of your work, so that they keep coming back and actually refer their colleagues to you.

The importance of User Interface investment is sometimes a controversial topic. I've seen people argue very passionately on both sides. I'm a gear-head by trade. I came up through the ranks of development organizations and am certainly not a graphic designer. But I'm often the minority in the development organization when it comes to my strong beliefs in putting User Interface first. Developers pride themselves on not being influenced by shiny, glitzy User Interface baubles. But baubles are not what I'm talking about, of course.

If the scale your success is going to be measured on, is how often you get repeat business, and referrals - how many fans of your work you create; and the people doing the scoring are your users, then it's clear that User Interface design has to be your priority. Nothing is worth doing if it isn't worth doing well.

Here's a bit of irony: I'm currently developing a software product aimed specifically at development teams (Devshop.com). These are the very folks who claim to be immune to the hypnotic effects of a great User Interface, and argue regularly that it's not important, compared to all of the very technically challenging things (and interesting things to them) that happen on the back-end. I've demo'd the tool to close to 50 of these people in the last 6 months. More often than not, one of the first things out of their mouth is, "Wow. That UI is incredible." Their eyes light up when they say it too. It's like a little spark of desire was created inside them. Now I know that as long as my feature set is comparable to others in my category, they will desire mine more than the other guy's, because I took the time to do one thing better than the next guy: focused on User Interface design, to make my end-user's experience actually desirable. I put the user first, brochure second.

More General Purpose Project Management Theology Isn't Helping Matters!

2005-10-24T09:10:00.000-05:00

I spent the bulk of yesterday searching the 'Net for focused, practical project management for software development. What I found was not very inspiring. I have to admit, I've been preaching for a while that overly generalized project management theology doesn't work - at least for software projects. How can I say that? Statistics. 70% of software projects fail. I didn't do the research personally, but it's fairly well known. One particular company (The Standish Group) produced quite a famous report (CHAOS) on the subject if you don't believe me. You can't say things are working when 70% of the projects fail. Something's fundamentally broken.

A couple times this past year, I've gone out in search of the kind of specific nuggets of wisdom and experience that can help dramatically improve the chances of success for software projects. So far however, the project management discipline at large seems to creep along, abstracting ideas further and further out to make them equally applicable to every kind of project, and none.

Here's some of the so-called "wisdom" I've found in my journeys:

[Good Planning] Take the time to plan your project properly. K. Thanks.

[Agreed-Upon Objectives] ...that can be reviewed throughout and at the end of the project to ensure they have been met. Come on now, we all know that no set of product requirements ever look the same at the end of the project as they did at the beginning of the project. How about some help dealing with that?

[Milestones in your Schedule] ...will assist you to measure real progress. Oh we have the milestones alright, trouble is they're never reached on-time.

[Resolve Project Issues in a Timely Manner] Don't slack off. Gotcha.

[Assess Your Risks throughout] ...meeting with your team... We keep telling the project sponsors that changing their mind's every week keeps delaying the delivery of the project, but they don't listen or think we're just whining. Give me something real to go to them with.

The trouble with all of the advice out there that I've seen is that it's ineffectual. It's definitely hard to argue with because on some ultra high-level, it's all true. But that doesn't make it useful. It's like saying, "You need to work hard to be successful." Gee, thanks. Give me something tangible please. Something I can do tomorrow that will have a real impact.

There's another related process called "The Demming Wheel". Plan, Do, Check, Act. (PDCA) [Every good process or methodology needs at least a 3 letter acronym, afterall]. There's a whole lot of fluff behind each phase of course, but it's all so utterly abstract that it's just a vehicle for false hope, unless you can make it tangible. SDLC's (Software Development Life Cycles) are a dime a dozen. Everyone's got one they think is magic. And still, 70% of software projects fail.

I honestly don't understand why more people aren't focusing in on certain types of projects more, when developing methodology. Maybe because the more specific you get, the more you can actually be held accountable. Application development is more than a $10 billion dollar industry. Surely it's big enough now to stop folding it in with the project management mother ship and create a specialty around just managing software projects, with all of their unique challenges, risks and techniques?

This is what I'm currently working on in the shadows right now, with Devshop.com. I plan to blow your minds in the new year. My big bold claim is that I've boiled down the essential elements of success for software projects, and am building a product around it to capture and share it all with you. It may not be applicable to any other kind of project, but for software projects, there's nothing else that can touch it.