It's not about tools; it's about people

Last week a collegue of mine did an introductory talk about RUP (Rational Unified Process). It was an interesting talk about how RUP can be applied in projects, what the philosophy is behind RUP, and lessons learned during her first RUP workshop.

After the talk, we discussed how RUP looked a lot like DSDM, Agile and XP. In all these methods, developers are arrogant enough to "demand" customers to conform to their process. Sure there is a lot to be said for consulting the customer often, and having lots of pre-releases, but the customer is still the customer, not your in-house QA department.

The past 33 years, a lot has changed in the computer industry. Computers have become much faster, programming languages much more powerful, offices have airconditioning and good coffee, and you no longer need to have a soldering iron to be a good programmer.

However, in the past 33 years, people have not changed. Programmers tend to fiddle too long with a cool, simple, fast but wrong solution to a non-existing customer problem. Managers tend to report "on schedule" while actually they are behind schedule. Customers think that the testing phase is there to be removed in case of a time/budget problem. And still, the majority of people think that simply hiring more people will get the job done faster.

The real problem in a project is not hardware. It's not software. It's not planning. It's not RUP, DSDM, Agile or XP. The real problems in a project are people.

Luckaly, we're not all lost. Some projects actually do get finished on time, on budget, and with all features included. These successes are often attributed to the methodologies used, the brilliant programming language, or the good weather. Do you know what I think? These succeses are nothing more than the result of a good team of people, who actually care for the project to become a success. A team which has enough common sense to know what to do, and when to do it. A team which gets a kick out of having a happy customer.

Writing computer programs is a bit like solving a lot of puzzles in a day. It's a creative process, and although you can make rough estimates, you'll never know how much puzzles you are going to solve today. Writing programs in a team is a bit more complicated. You need to know what your team members are up to, and what their strong and weak points are. Deviding the puzzles between the team members needs to be done with great care.

Having a process like RUP or any other (maybe self-made) process will be fine, but will only work if everybody in the team knows why this process was introduced,what it solves and what their role is in that process. If the goal is clear, and the team is a true team, the members will have no problem correcting eachother, and accepting corrections from eachother. It will become a sport.

So the real solutions in a project are people. More precisely: people who take their profession seriously, 24x7.