.comment-link {margin-left:.6em;}

Uncommon Sense (for Software)

This blog has been moved to www.UncommonSenseForSoftware.com.

Wednesday, March 29, 2006

Uncommon Sense (for Software) is moving...

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!

Tuesday, March 28, 2006

My dreamPod

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. 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. 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. 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. 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. 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. 6. PIC button - 'cause for candid pics, you've gotta be quick!

  7. 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...

Monday, March 27, 2006

Tembria - Server monitoring for the rest of us.

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.

Wednesday, March 22, 2006

More on the upcoming Ottawa BarCamp

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!

Friday, March 17, 2006

Review of Devshop site

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...

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


Wednesday, March 15, 2006

Death by a thousand cuts

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.

Thursday, March 09, 2006

BarCamp Ottawa Coming Soon

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

Wednesday, March 08, 2006

Project Management Quotes

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.

Thursday, March 02, 2006

The Power of the Suite

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:

  1. 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.

  2. 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.

  3. 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.

Wednesday, March 01, 2006

Contact info...

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.