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.