From the monthly archives: February 2007

I always wanted my blog to be about my thoughts on software engineering. I feel they have matured long enough now for me to try and write them down. Hopefully, this is the beginning of a series where I give my opinion about what’s important when developing software.

Some would argue that process is at the center of software engineering. However, that word often often brings nightmarish visions to people, visions of activities with multiple signed handoffs of deliverables, usually including a ton of documentation. These are what you would call heavyweight processes. There are of course lightweight processes and agile processes. When I talk of process, I don’t want you to think of any these. I want you to think of what you and your team do every day, of the way you are organized, the way you work to get software done. That’s your process. It may have a name, it might be documented, it might only exist in your head. No matter what, you always have a “process” when you work. It might simply be whatever works (by the way, that’s an awesome process). This article is not about whether process are good or bad. That’s irrelevant, because by the simple act of working, you have a process.

There is an attribute that I think is very important for a process: habitability. This is an idea I came across in the book Crystal Clear, A Human-Powered Methodology for Small Teams, by Alistair Cockburn (p.232-233):

Habitability became a top priority when I started noticing in my project interviews that most programmers have the power to ignore whatever methodology is mandated by their organization. All they have to do is say that it slows them down and they’ll miss their deadline if they do all that extra work. That is usually sufficient basis for ignoring it. [...] If the programmers are told they have to do it anyway, they usually find ways to circumvent it. It doesn’t matter what the methodology is if it doesn’t get used. In other words, habitability is a critical success factor of methodology adoption.

Part of habitability is tolerance for human variation. Some like to make lists, others don’t; some work best visually, others with text; some like to work alone, others in groups. Some stare at the design for hours, days, or weeks making sure it is right, while others like to “feel” the code taking shape. It is for that reason that Crystal has so much tolerance around techniques – not only do they change all the time, but different people are drawn to different techniques. The habitability priority means that the rules need to be such that the people on the team can live with them.

Emphasis mine.

The process you use should fit the team. That’s what habitability means. The process should not go against the way team members like to work. That’s what is meant by the Agile Manifesto, “individuals and interactions over processes and tools”. People have a first-order effect on software development (an article by Alistair on the subject). The process is there to help the team deliver, not the other way around.

That’s all there is to know about software process. Good people will find a way to deliver, whatever the process. That does not mean to use any process, but to use one that will make the team happy. And happy people are more productive.

Popularity: 53% [?]


I was reading a sample chapter of TextMate Power Editing for the Mac about all the bundles in TextMate. Of course, the one for html is really nice and solves almost everything that I hate about writing a blog post. Looking through the rest of the bundles, what do I see? One for blogging. I’m pretty you know by now what happened next.

Popularity: 4% [?]


I wanted to write a more detailed post about CUSEC, like I did last year. I tried a couple of times but I couldn’t find a really good way of putting it all together. I always wanted my blog to help me get better at writing. Maybe I put too much pressure on myself to write a long article.

However, there certainly were a couple of interesting ideas I heard at the conference that I want to share, or at least that I want to catalog in my blog. So here they are, at random (well not totally, in the order I heard them):

Day 1

Pete McBreen

  • The "It works as designed" mindset. (There was a very funny example about a motorcycle, anyone remembers what it was?)
  • We should sign our work, take responsibility for the systems we create.
  • Learn from experience with project retrospectives.
  • We need to promote fun process because excitement is a good predictor of quality.

Austin Hill

  • Startups can stay small today.
  • VCs expect market traction for a software company, so it’s important to get it out soon.
  • Find mentors and coaches.
  • Technical risks are low today. You take creative risk.
  • Forget plans. Have fun. Choose what not to do.

Greg Brill

  • Aptitude. Attitude. Experience. Favor the first two.
  • Elevator pitch can be summed to "What do you want?".
  • Trust your instincts.
  • Attitude is king. Avoid the bitch cluster.

Other presentations of the day:

  • Jim Cordy about what is a professionnal software engineer.
  • Someone from SAP talks about Web 2.0

Day 2

Dave Thomas

  • Dave starts his presentation by taking off his shoes.
  • Use of fear to manipulate. FUD is used to sell.
  • Risk management is important
  • You can’t live without taking risks.
  • Do not be afraid to make mistakes.
  • Opposite of risk is stagnation.

Ralph Johnson

  • The word maintenance has a bad stigma.
  • Maintenance is increasing.
  • Programming is program transformation.

Other presentations of the day:

  • Dr Lee McIntyre about the User Experience team at Business Objects.
  • A presentation of Mylar, an interesting plugin for Eclipse.
  • Panel discussion wasn’t very good, lacking direction and a central theme.

Day 3

Venkat Subramaniam

  • The key to beginning agility: attitude.
  • Fixing problems is a top priority, not blames.
  • A mistake is an oppportunity to learn.
  • Keep up with change, but keep your balance.
  • Take control.  Find a rhythm for everything. Tackle tasks regularly. Set small goals.
  • Don’t listen, educate customer.
  • Decide what you shouldn’t decide.
  • Timeboxing.

Other presentations of the day:

  • Geoff Guenther, about high performance databases at Direct Energy.
  • Timothy Lethbridge, about the resistance to HCI.
  • Kokoromi

Well that’s it for CUSEC for 2007. Going through my notes, there clearly was an idea that come up a lot: Make mistakes and learn from them.

Popularity: 4% [?]


My last post got a trackback, which is really cool, especially considering my posting frequency ;) . It also happens to be an awesome post jam-packed with juicy stuff, titled Canada’s Mojo Rising. It’s from Austin Hill, which I talked a bit about in my last post, and it’s about the emerging tech entrepreneurship in Montreal. Reading his post made me realize that I really need to start networking and it also provides a great list of starting points with upcoming events. I’m a bit ashamed that I didn’t attend the DemoCamp at CUSEC. Fortunately, it’s not too late to start!

Popularity: 5% [?]