What’s more important: Process or tools?
I’ve sat through numerous arguments with people trying to work out whether process or tools are more important to their software development effort. The arguments go along the lines of:
Process Geek: Tools are just the things you use to do the process, the value is in the process. Let’s do a process first roll out.
Tools Geek: Tools are the things people actually use. Process is academic and is constrained by the tool features anyway. Let’s do a tools based roll out.
Sadly both of these are real life quotes from people I’ve worked around in the past. I won’t embarrass them by naming them because they’re both really wrong. For me the real value is not in the tools or the process but in the people. Process and tools are something that you add if the people need them.
For me the best planning tool is a whiteboard. The best architecture and design tool is also a whiteboard. I like to capture some info about what I’m doing and how close I am to achieving my goals, some really simple measures. The best tool for that is probably Excel, despite my love of Open Source. Other than that I need to manage some lists of things like requirements (stories/use cases whatever), defects and whatever other bits the team thinks are important. They might fit on a whiteboard but typically we want to have some attributes on them, be able to sort them and link them. The one downside of a white board is the lack of drag and drop. I’ve used a few different types of smart board and active touch screens but none of them have really given me the smooth experience I want.
This is potentially a can of worms if I go into things like process kernels and ideological arguments about different agile approaches and practice collections. There’s no such thing as a process silver bullet so for me though it’s all about the team and being effective. Teams need to:
- Have Clear Obligations
- Have Clear Business Priorities
- Seize their autonomy
- Have the relevant technical skills and resource availability
- Be active in actually doing their work (seems obvious but it’s something a lot of processes seem to hinder rather than help)
- Demonstrate visible progress (via working software not a tracking gantt chart)
- Continuously improve themselves (because no way of working is perfect)
This list based on the 7 Habits of Agile Teams by Roly Stimson
So why go more complicated?
Unfortunately life is rarely simple. Many teams work in complex environments where a number of factors might make them choose to need more than this kind of minimal set including things like physical distribution; audit, regulatory or security constraints; cross-team interaction in system of systems environments, more people etc.
When faced with increased complexity it might be appropriate to add more powerful tooling or development practices. The more people involved in a project the harder it is to herd all of those socially complex cats into working together.
This is why ALM suites exist ranging from plugging together some open source bits like git, SimpleGit, jenkins, agilefant, bugzilla etc. to commercial vendor products like IBM Rational RTC (which does agile planning, work item management, scm and build in one tool) and other IBM Rational Jazz tools – it’s worth noting that you can also get RTC for free for just 10 users or for academic/research use on jazzhub.
Alternatively there’s Microsoft TFS for source control, work item tracking etc. tying together existing Microsoft stuff like MS Office, Visual Studio and sharepoint if you’re a more Microsoft focussed development house.
Of course you can also mix and match this stuff to a greater or lesser degree with various integrations. No toolset is a silver bullet however and each have their own problems.
So what’s my point?
My point is that process and tools need to reinforce each other, that both should be selected based on the needs of the team and the environment the team has to operate in. In the process vs. tools argument both lose out to the people. People in a development organisation create value, they just use tools and process to do it.
Pictures that are worth 500 billion words!
Google Ngram Viewer shows graphs of how many times words or phrases have occurred in a set of 5 million books over the years. They’re a really interesting way of seeing trends in information and relative importance between words. It’s free and easy so check it out.
Here’s some I recently ran that I found interesting. I ran most of them from 1950 onwards and the info only goes up to 2008.
Comparison of programming languages
Ngram link – When looking at this you’ve got to mentally remove the baseline Java and Pascal references from the 1950 as they’re about coffee, islands and mathematicians. Interesting to see Java so dominant.
Ngram link – I found this one really interesting. Compared to the others in my query “structured programming” had a lot more books written about it. I wonder how much this is a reflection of the rise of the internet… these days although there are lots of programming books the primary source for learning a language is online material?
Ngram link – I was a little surprised to see RUP so much more prevalent than agile but then I did have to add “software development” to the term to avoid including the bendy and stretchy. Also as with the previous one I suspect that there’s a difference here between a vendor driven process with supporting books and a more open source philosophy on agile as a generic umbrella for methodologies, and therefore more online sources. As Ivar Jacobson says: “No one reads process books”
Shareware, Freeware and OSS
Ngram link – This one speaks for itself 🙂 I wish I could have worked out how to add “expensive vendor products” to the query!
User Stories vs. Use Cases
Ngram link – Ah yes, this argument again. Interestingly this dominance of use case over user story in written books correlates with query stats between user stories and use cases on by blog and the ivarjacobson.com site. Personally I think they’re both great and complimentary, I often use them together on software projects.
Windows vs. Linux
For more fun with Ngrams watch this very funny video explaining this stuff