From the monthly archives: January 2006

In the next few weeks, I will be going through the backlog of things I accumulated in the last months that I want to touch in this blog. The first one dates back from october, but ties in nicely with my last posts about CUSEC. It’s from Martin Fowler.

This approach – some people report their story, others copy it with or without success – is the backbone of how a profession can learn. The fact that it’s anecdotal doesn’t stop it from working – after all much of our entire economic system is built on people building on each others’ anecdotes of how businesses should be run.

MF Bliki: AnecdotalEvidence

It’s very tough in software engineering to come up with empirical evidence on a particular practice. Some would say it’s impossible. So we have to rely on anecdotes of what worked for someone on a particular project, in a specific context, with individuals, etc. There are a lot of variables involved which make it difficult to reproduce the practice in your situation. However, it’s the best we can get and it doesn’t mean we can’t learn anything. In fact, I would argue we learn more because it actually forces us to acknowledge the differences in what we’re doing and it forces us to better adapt to our circumstances.

It’s important for our profession that people discuss what they’ve tried, what worked for them, what didn’t, etc. This is why I think conferences like CUSEC are very important. It’s a place to gather and share our experiences. The presentation from Motorola on their adoption of agile practices is the best example of this.

Popularity: 10% [?]


David Heinemeier Hansson, Rails creator, was supposed to give a keynote on Rails, but his plane was stuck in Seattle. Bummer. Chad Fowler pulled double duty and gave a presentation titled “Ruby is a Toy and Rails is Boring”. Ruby is a toy because it’s actually fun to program. Rails is boring because you don’t have to spend a day to install Tomcat and configure a bunch of xml file. He gave a very brief example of rails. Most of the presentation focused on the philosophy behind Ruby and Rails, like the idea of convention over configuration. He asked us to always question why we’re doing something in a specific way, and see where we can apply the same philosophy to other languages.

After a presentation on software startups, the panel discussion was next with Chad Fowler and three students. The usual question of the difference between computer science and software engineering came up and caused again quite a stir. As always, I noticed two debates going on: the situation right now and what should be. Most software engineering curriculum are pretty new. It’s no surprise then that computer scientist have been doing engineering until now. However, I think it’s time to further separate the two, just like in every other field. Engineers will build software, while scientist will research better and new algorithms, data structures, languages, distributed systems, operating systems, etc.

That’s the end for CUSEC 2006. It was a fun event. There were three keynotes that were very good, two by Chad Fowler and of course the one by Kathy Sierra. I’m still thinking about first one from Chad, it’s made me see my career in a different light. I had to order his book and I just received it this morning from Amazon.

I’m looking forward to CUSEC 2007!

Popularity: 5% [?]


No surprise here, but the best keynote ended up being Kathy Sierra, Creating Passionate Users. She knows how to keep an audience engaged, which you would expect since part of creating passion actually comes from learning and knowing how to help the brain notice things. Most technical writing focuses on the mind, the rational part, and expects you to learn just because you want to. However the brain doesn’t work that way. It has a crap filter, otherwise you would go insane. Kathy then talked about a lot of techniques to force the brain to take notice, things like misattribution of arousal. This is when the brain remembers something because something else, good, was happening at the same time. It’s also important to mention at the beginning why your audience should care about what you’re trying to say.

Head over to her blog right now and start reading. You won’t be disappointed. And remember, it’s all about helping our users kick ass.

Popularity: 4% [?]


Friday afternoon, I attended another presentation on testing by a gal from Autodesk. The title was “Testing in a Creative Environment”. I expected something more about the difficulties and particularities related to the creative part. It ended being nothing more than the importance, the role of the QA team. It was a bit disappointing in that sense but still ok.

The next keynote was about formal methods, a dry subject. Add the worst case of hum I hum hum from the speaker, and you had half the audience asleep. Formal methods work for a very specific type of software when you need high reliability and zero defects. That was my impression before and it remains that way, and that’s what Connie Heitmeyer, the speaker, acknowledged.

A presentation from Dr. Peter Forbrig, from Rostock University in Germany, followed with “Model Based Development of Advanced User Interfaces”. His English was good, but still a bit hard to follow. He had some kind of UML application that allowed to generate UI and add patterns and get a simulation of the final UI. It seemed to go in all kinds of direction. There were some cool stuff but the project seemed to lack focus. I guess that’s what research is for.

Popularity: 5% [?]


On thursday, I also attended a presentation on “Software Testing as a Social Science” by Cem Kaner, from the Florida Institute of Technology. It wasn’t bad, but he spent so much time with traditional definitions of testing that he barely had time to scratch the surface of the social aspects of testing, and missed an opportunity to come up with something really interesting.

Friday morning I went to a talk on an agile experience at Motorola, a CMM level 5 organization. Unfortunately, I did not have time to ask what obstacles this posed to the implementation of an agile process. Things however seemed to go pretty good. The second release delivered the same number of new features in half the time with half the people as the the first release that was only using an incremental style of development, but otherwise the same practices as traditional waterfall inside Motorola. The speaker gave cautions on a lack of documentation to help new members get up to speed (I would have thought that pair programming would help here). He also mentioned that automating tests can be very time consuming, which is something that I’ve experienced myself.

The next keynote was by Peter Grogono, from Concordia University, about modular concurrency. His plan was to show that OOP has problems and that something better is needed. He of course showed trivial examples in Java to prove that you can do stupid stuff. Duh. So OOP is bad because Java made some stupid choices, especially when it comes to concurrency. Things got more interesting here as he mentioned research that was done in the seventies that offered much better and safer concurrency than Java does today. He quickly showed an example of what he is developing, something that uses “cells” to separate modules. However, his example was the traditional hello world that took 20 lines of bizarre redundant setup. But there was an interesting concept here where the deployment of the code, meaning where it will run, what process, can be changed separately from the the actual program because of the way the language is designed. If I understood correctly, that means you could write the program without worrying too much about concurrency (but still making things modular) and it would be easy afterwards to scale or parrallelize the execution of the program across machines. This talk would have been very cool if Dr. Grogono had skipped the useless and pointless OOP (Java) bashing.

Popularity: 80% [?]


CUSEC opened on thursday morning with a very interesting keynote from Chad Fowler, author of “My Job Went To India”, titled “Fight the Traffic”. He first went through his career from computer support to CTO for a year and half in India. Doom is responsible for his passion for computer. He recently decided he wanted to be a ruby programmer and seems to be hapy with his decision, doing what he loves.

He then explained his view on software development, how he views it as a craft (he doesn’t like the term engineer). But no matter if you define it as art, science or else, software development is a business. But if you see things that way, your job will go to India. Business people see software development as a commodity. Chad however doesn’t feel it’s a bad thing, as only the boring jobs are moving, the ones you wouldn’t want anyway.

There are a lot of opportunities if you are passionate about software, if you want to craft something. He then gave suggestions on how to enhance your career: practice, know your audience, blog (to improve your writing skills), start a project. He also mentioned the long tail, how there are many opportunities for applications that target a specific audience. He finished by saying that the path is greater than the destination

This talk has given me a lot of food for thoughts. I cringed when I first heard him talk of software development as an art, a craft. I still have fundamental issues with that view, but he made a strong argument against the engineering view. The problem with it is that it makes it easy to outsource your job. However, as a crafstman, there are still a lot of opportunities for me to develop something cool, have fun and make a decent living.

Popularity: 6% [?]


In the last few months, I have accumulated quite a lot of blogging material. I will get on a weekly posting schedule.

My first post next week will be a retrospective of CUSEC 2006, a conference on software engineering here in Montreal. We have mr. Rails himself, David Heinemeier Hansson, talking and also my favorite blogger, Kathy Sierra, of Creating Passionate Users fame. I can’t wait!

Popularity: 4% [?]