Previous blog posts have outlined a better alternative to a software process. Software project activities will be improvised according to the concrete situation: the kind of the project, technologies used, people in the workgroup, people on the customer side, and the contract details.
To go this way, you need competent people who understand how and why software processes can work. You need motivated people willing to use their knowledge for their employer. And you should be able to trust them.
Software processes on the other hand promise to work with just any kind of employees. Just have them do the steps defined in the process, and make them accountable for adhering to it. The only absolutely necessary feature employees must have is the discipline. And because employees whose main skill is discipline cost less on the labor market, you can develop software cheaper and thus raise the efficiency of operations. So the theory.
The notion of processes used as substitute of competency and creativeness is so immediately ridiculous and obviously wrong for everybody who was in this business for some time that I’m not going to spend much words arguing. But it is still interesting to investigate, why this idea seems to be so insane.
Let’s examine a basic software developing activity: the coding. It consists from several atomic operations like typing text, editing text, saving file, searching for a substring, executing an application and so on. Everybody including my mum and her dog can learn how to do these operations, after a 3-month course. But, applying the right operations in the right order and knowing what to type cannot be instructed.
You can learn capitals of every country in the world. You can learn 3000 words of a foreign language. You can memorize them. But you cannot memorize how to code. Because it is different in any new situation. And computers will never forgive you for any small mistake: while you can still become an average cook by memorizing tons of recipes, you cannot become an average programmer by memorizing all the words in a programming language.
What you have to do is to improvise each time you code. Your first improvisations will be extremely bad. You repeat and repeat them again, and you slowly improve in it. And when you reach the level of proficiency, you cannot dump your brain so that others would ingest it and immediately obtain your skills. Because it is your subconscious, which will be trained, and your subconscious is highly specific to you, your childhood, your genes, your environment and the history of your life. It is useless for anybody except of you.
This fact has a couple of interesting consequences for knowledge sharing, software developers working in groups, dealing with source code from others, and colleague-to-colleague learning, but I digress.
The need for improvisation is also required in the basic activities of other professionals participating in the creation of software product: you can memorize all Photoshop features but it won’t make you a graphic designer; you can learn by rote books about handling conflicts, but it won’t make you a project manager; and you can know the test script by heart, but it won’t make you a software tester.
Ability to improvise is a required skill to get things done in the software development business. No software process can replace it, when it comes to getting hands dirty and actually develop the software. A certain level of experience and creativity is needed anyway, so no software process would really allow to hire people whose main skill is the discipline.
Now, it can happen that particular software professionals are experienced enough to code, but are not experienced enough to be able to select proper course of actions depending on the particular situation. Wouldn’t a small nifty software process guard them against mistakes simultaneously showing them one of many possible ways of software development?
I believe, the answer is no, unless there is someone adapting their software process to the current situation, on the daily basis. If it isn’t happen, they end up doing mistakes ACCORDING to the process. And, they will not accept these mistakes as their own mistakes. So they don’t learn from them and will not try to improve the process. Because, “hey, I’m doing everything exactly according to YOUR process, so don’t blame me, go change YOUR process yourself.”
The better alternative to that seems to be pairing software professionals with more experienced ones. So they can observe how decisions are taken, ask questions about the reasons; and take their own decisions on topics delegated to them and get a feedback about suitability of those decisions.
Say, if I want to be a team lead, I am assigned to be a part-time associate team lead of a project. My job is mainly observing what the chief team lead does, accomplishing routine tasks for him to polish my skills, and temporarily replacing him when he is on vacations or not available. After several projects, I may feel to be knowledgeable enough to take over the chief team lead responsibilities. Of a small simple project, of course :) I think, this idea is worth to be tried out.
Leave a comment