A few days ago I came upon an article by James Turner about processes killing developers passion and which when you read you get like “whoa, he’s right!”.
It can be easy to fall for this kind of trap and which is why I try to counter it.
Developer passion is indeed one of the great assets a software company needs, but in the end, we – software developers – need to deliver what our client needs. In the 21 century this means large scale enterprise applications, large multiplayer games and the likes, essentially software that require more than 2 people locked in a basement to develop. This is where the need for processes arises, because no two developers are the same. Each favors a certain technique or way of doing things and this leads to … problems. Processes, if implemented right will make sure all developers have the knowledge they need, will allow for estimates and plans, such that the client knows when he receives his product. Even more, processes make sure that the product has the quality required by the customer, not the quality perceived by the developers. We all know this picture. In order to counter something similar to happen we put grooming in place, we get planning sessions and make sure the customer is always close by to check that we do what he thinks he wants.
I can understand that processes might be poorly designed and make the developer’s life harder instead of making it easier, but this is like saying that in Europe is most of the time raining because it is so in UK. I do PQA (process quality assurance) and I always have to ask myself: “do we need to apply this process as it is or change it in such a way as to get the same results and not to burden the developers?”.
Let us suppose you are a bank and need a new backend system. Your bank will move billions each day. What do you do? Will you choose a small very “passionate” company, or go for one that has processes in place and are transparent in their work and give you measurements about productivity and quality?
Of course, your company might not be a bank, and you do not expect something great, only something that it works and fast. Jump on the passionate wagon, they will certainly deliver.
Maybe the real problem resides in “when” should you apply all the TDD, reviews, processes, measurements and the like. I can only say: do what is needed to achieve your goals. If the goal is “zero defects” (I don’t agree with that but that’s another story) then go for the full-blown processes approach. If you need something fast, get a senior and a few devs and juniors, give them free hand and you are done.
Today I was chatting with someone from the company about the same article and he said: “if someone thinks that putting 5 guru’s in a team and letting them just do the product will work, I am willing to bet ALOT against it happening”; and I tend to agree, unless they devise their processes and plan the project to a certain degree, which if they are passionate enough – will not happen.
Cheers
Entries (RSS)