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

Uncommon Sense (for Software)

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

Thursday, February 23, 2006

Presentation to Ottawa developer group

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.

Thursday, February 16, 2006

Design a couple versions at a time

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

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

Friday, February 10, 2006

In Software Project Management, Size Doesn't Matter

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?