Friday, July 16, 2010
On Tools & Methodologies
In one of Pablo Picasso’s most famous quotes he says that it took him four years to paint like Raphael, but a lifetime to learn how to paint like a child. Indeed, a sign of expertise is mastering one’s field to the extent that there’s no longer a need to abide by “traditional” rules. Great songwriters like Jon Mitchell, Bridget St John, and Nick Drake (of “Pink Moon” fame) tuned their guitars in an unorthodox manner; inventing new chords which helped them create uniquely melodious sounds.
Once during a job interview, I was asked if I preferred project management tool X over tool Y. I could not refrain from answering, “The tool is irrelevant! What matters are the people who will be using it!” Perhaps my answer did not endear me to the interviewer as I didn’t land the job, but the point remains: A better tennis racquet won’t make someone a better player (I proved this pseudo-scientifically by purchasing an expensive state-of-the-art beauty made of graphite that didn’t save me from losing game after game). Expensive tools don’t necessarily ensure a project’s success. In fact, blindly applying processes or fixed methodologies can easily be more of a hindrance and a problem than an assist.
Make no mistake, tools and methodologies are needed, but as a colleague of mine once remarked, “Only beginners need to follow every step and use every tool. Experienced people have gained the necessary knowledge to know when to bypass steps.” Along the same lines, author Phil G. Armour makes this great point in his First Law of Software Process: “A process only allows us to do things we already know how to do”. The corollary to his law is that you cannot have a process for something you have never done or known how to do. This scenario is especially relevant in the world of SOA as well as in the world of other emerging technologies, where tools and processes are still immature and evolving.
It follows that a large IT transformation project will require the use of repeatable processes in those areas that have been tried before. However, in an IT Transformation the biggest challenge is about creating something new. Processes in this context are not things that you must follow, but instead are things that you will have to create. Indeed, a key element of your IT transformation deliverables is to define and document the required processes to ensure repeatable success and continued operations of the new system.
How do you know which processes are needed and which aren’t? The answer is to assess you own experience, along with the experience of your team, and figure out whether there is a need for a process—any process at all. If there is no need for a process, then don’t have one! You do not need to apologize for this. After all, experience is all about knowing how to separate the essential from the superfluous. Do you still read your car’s user manual every time you are about to drive? (Did you even read the manual at all?)
If you are dealing with a senior development team you can only enforce so many processes, but if you are managing a team formed of very junior developers, they will actually benefit from the strong direction and clarity the following processes can provide. Now, let’s not confuse processes with standards. You should definitely have a well-defined set of standards, and your developers will probably want to have them as well. Do, however, keep in mind an oh-so-true observation Mr. Armour makes in his book: “What all software developers really want is a rigorous, iron-clad, hide-bound, concrete, universal, absolute total, definite, and complete set of process rules that they can break”.
You will need to assess how flexible you should be about these rules on a case-by-case basis. Ultimately, the range of tools and methodologies you will need to consider for a complex transformation initiative is rather large. At a minimum you should concentrate on standardizing the use of the following:
· Project Management Tools
· Libraries and repositories such as service registries and source code controls
There is some disagreement about whether to enforce standards on tools that are considered individual productivity enhancers. The line here is not always clear. Is a software development environment (otherwise known as IDE) something you should insist upon standardizing across your entire development group? I can assure you, programmers are typically compliant with much of the BS (Big Standards) they have to put up with (filling out those much-hated time reports, going through ridiculously convoluted change management processes, facing draconian purchase order approvals, having to change passwords every nanosecond, and so on.) but I have learned that trying to force them to abandon their preferred IDE tool is likely to set off a revolution of Bolshevik proportions. If you can identify two or at most three IDEs that everyone can use, then settle for those. You should be prepared, however, to accept that a year down the road, these IDEs will no longer be “the best” and there’ll be a new kid on the block everyone’s dying to use.
Conceding a little on tools driven by personal preferences should not mean that you will give up on enforcing truly important enterprise rules. How you do version control, for example, should be standardized and not left to a single programmer’s decision. Version control is a shared function after all. Focus on putting your foot down on the use of tools that have an enterprise scope and have to be shared by several people, as well as tools that support repeatable processes. But make sure you indentify these preferred tools as quickly as possible during the tenet-definition exercise. Failure to do so could lead to the adoption and rampant propagation of a zoo of ad-hoc tools, making more difficult the alignment of your enterprise efforts. Still, there’s nothing wrong with keeping the pulse on advances of technology so that if a new valuable tool emerges you can evaluate its use in an objective manner and adopt it on a disciplined manner, should you wish to do so.