Leo's Technical Blog

People. Tools. Processes. In that order.



Leo Soto

advising, software_engineering

People. Tools. Processes. In that order.

Posted by Leo Soto on .

advising, software_engineering

People. Tools. Processes. In that order.

Posted by Leo Soto on .

That's my common response to the question "What are the most critical factors for software development process?".


Does anyone question that having good, skilled, motivated people is a good thing? I don't think so. But it seems that there is no such general agreement on the proposition "good people is the most important factor in software development".

Well, I will justify my assertion when describing the other two critical factors, noting why they aren't as important as having good people.

Now, the topic of how do you identify good people for software development, or what are the qualities that a good programmer must have, is beyond the scope of this blog post and already discussed endlessly on many places. Just find the criteria that works for you.


Good tools improve productivity, and avoid wasting precious human time with boring, repetitive tasks. Bad tools (or no tools at all) force people to have a hard time solving problems not very well suited for humans.

But they aren't more important than people, because good tools in wrong hands causes "interesting" results sometimes and good people without good tools will produce good tools anyway, given enough time.

In others words: good tools are made by good people.


Yeah, processes are useful. They formalize some common and/or wanted behaviour. Documenting them make the life easier for new people coming into your development team, and keeps things clear.

But they aren't more important than people. Throwing a process to a bunch of unskilled people will only help (if anything) to get predictable poor results. That may be better than plain old chaos, but it's not too high on my scale.

On the contrary, good people can see where you need a process and where you don't need it. Again, good people create good processes. I'd say that the better processes are the ones where you want to formalize and repeat an _already successful _ behaviour.

Finally, it's better to have good people plus good tools than good people plus good processes. Believe me. Still not convinced?. OK, I was just trying to keep this section short.

It's better because processes are determined by the available tools. Sometimes a good tool makes a complete process irrelevant, or greatly simplify a process. And remember that a process tends to have a considerable amount of inertia so are difficult to change.

So, setting a process when there is no good tools in sight may make stupidly hard to adopt a good tool when it is available. Besides that, there is a good chance that what the process is doing is no more than a work around, not a proper solution.

Real case: some of the customers of the company where I work have really big codebases. To make such codebases somewhat manageable, they have setup scary processes, multiple environments that must be merged manually many times, and force providers to write documents explaining what artifacts are new, what is being changed and what should be merged and how. And they use (or misuse) ancient revision control tools. I admit it, their problem is hard, and just recently we are seeing tools that can manage a high amount of parallel changes to a big codebase (such as GIT, Mercurial, BitKeeper, etc).

But they focused on the wrong side of the problem, and tried to mitigate the observed symptoms instead of questioning the root causes and improving that. And now that the open source community have a myriad of tools that fixes the problem (or a big part of it) they will not be adopted on the short term because everybody is used to the stupid process and the fear of change is too high.

Some final words about processes: They should be "agile". Yeah, I know that "agile" is a buzzword, but I'm referring to agile software construction, opposed to the Big Design Up Front methodology. Processes should be iterated over and over again, because only in reality some problems (o potential improvements) will be obvious. And the smaller the process, the better. I mean, it's OK to have one process to do code reviewing, another to do major releases, other to deal with security problems and so on. But avoid throwing too many problems to one big process. It won't work.

I also planned to present a few examples where the people->tools->process work. But this entry is already too long so I will save the examples for a later entry.