Convergence in the field

During the PHP Quebec Conference, I had one of those weird feelings. It was just like my profession changed overnight, in a good way. It happened while I was talking to Eric David Benari close to the coffee machines at a time we both should have been sitting in an other room listening to a talk. Earlier that day, he had given an introduction talk about project management. He was surprised by how smart the audience was after one of his barometer questions. The question went a little like this:

Jeff is a hero in the company. He often pulls out all nighters, work on week-ends and always saves the day before releases. Rita works 9-to-5. Considering they both do the same amount of work, who should be getting the largest bonus at the end of the year?

I will leave to you to determine what the answer was. Eric David’s surprise was because, for the first time, he saw the audience completely divided, instead of being skewed towards one end.

I myself saw a difference after my presentation on software estimation, which I got scheduled to do only a few hours before the conference to fill up a canceled slot. I first gave that presentation in 2006. At the time, most people thought the idea was weird. While I hope some decided to try it out, I doubt that was the case for the entire audience. This time, I wanted to make it more interactive, and most figured out I wasn’t so prepared, but a few came to talk to me after the presentation to tell me how they handled empirical data and get some advise with some problems. For the first time, I was not alone in the room using valuable estimation practices.

Sure, I have not been alone in this world to do it. I mostly learned from other’s experience. The surprising part is that we are no longer isolated. Have we reached a critical mass? Are there enough software engineering practitioners out there to really make a difference and apply the principles? For a long time, the field has been founded and promoted by a few very bright individuals struggling to get their message through. Today, I see their message as finally spreading.

Every PHP conference I attend has a few sessions on either agile or best practices in some way. These sessions are not the least popular. Even technical crowds are moving their focus away from code. It really wasn’t the case back in 2003. Even some apparently technical talks are in fact process talks in disguise. Sebastian Bergmann‘s classics on PHPUnit are good examples.

How did it happen? Joel Spolsky mentioned that it was a bit useless to write about best practices because the programmers who need it are the less likely to read it. It seems that, while they don’t go out to read books and articles, there is only so much that can be ignored. Blogs made the best practices omnipresent. Podcasts brought them to the lazy ones. They reformulated the tried and true techniques in a way others can understand. Even thought not everyone is reading or listening, I have the feeling communication got to a point where every company out there can now have an evangelist.

Could time alone simply have made a difference? I’m part of a brand new generation of software developer. I was born after all the problems have been recognized. My training was focused on other’s mistakes so I don’t have to make them over again. Every year, a few hundred more software engineers graduate with a better training, knowing the best practices and development processes, not only the coding part of the equation.

Could it be the different crowd? Technical conferences attract younger people in general. People who are usually down in the trenches. Managers are rarely around. Most of what I read these days seems to have a common theme. The theme was present even in books written over 15 years ago, but it’s now getting louder. No matter what you try to do, only one thing will make a difference in the end: commitment to quality work. No methodology will work unless the team agrees with it and embraces it. No estimation technique unless will work unless those who estimate take it seriously. TDD will fail if developers barely attempt to reach code coverage standards. Robert D. Austin explained this phenomenon a long time ago.  Developers know this instinctively because they can see the difference between real and fake. How long will it take until organizations realize it?

The good part to this is that if you have a good team, almost anything will work. Even if you do it all wrong according to the books. There are tons of methodologies out there. Agile alone has a dozen, and there are even more unpublished variants. They all worked at some point, most of them probably failed to repeat with a different team. Formal methods are being laughed at these days, but I have no doubt they did work at the time for the context they were created for. However, simply taking them as a set of rules and enforcing them on other people is bound to fail.

Leave a Reply

Your email address will not be published. Required fields are marked *