I was always in opposition of software development processes, because I always felt that the processes are meant to diminish the skill of individuals creating software, adding an overhead that creates no value.
Seems, I was right. Indeed, I always preferred ad-hoc organization, direct responsibility for code and for the results of what you do. I overlooked intentionally the politics involved in software development - all the managerial chess-playing that makes the product go live and live instead of being a simple storage issue in the code repository. It might seem like a huge thing, but it's really not - it's people doing their job. The software processes were meant to make the people that usually don't get along to get along. Unfortunately, software writing people are not the ones that have a say in this, so software processes are fitting better the managerial people rather than the people actually doing the work, the software people. Ad-hoc processes usually mean that the software writing guys doing things as they know best. Established processes is software writing guys doing things the marketing way. And it doesn't work.
The current disappointment I have regarding the processes concerns SCRUM, but I'm pretty sure that it's not just SCRUM... it's all of them. All the software processes are meant to transform the programmers into working bees, working bees that produce the same quantity of honey month after month, even if it's winter time and no flowers are around. Useful, predictable slaves, that, like in the fourth grade math problems, 'dig 20 meters of trench in 2 day, therefore 100 meters in 10 days'. Everything is measured, the creativity is measured. But there's a catch.
Imagine SCRUM in poetry. People gathering around, looking at how many verses you finished today, which one will you write tomorrow, what impediments you have in writing your poetry. But you can't really calculate how much poetic spirit is in a poem, can you? So there's a solution from the managerial team. What we used to call 'self-critic' - something that reminds me so badly of the communist time - but now it's called "inspect and adapt" or, even better, "retrospective". We do it, because that gives us freedom. The freedom to continue with this world of scribblers and slaves. The scribblers accounting for how many poetry points you scored today, why your score wasn't good enough, and how can you improve. How fast can you make old ladies cry, why didn't you do it faster or in better shape.
And all this time, you'll wonder why your poetry lacks soul, biting from a tasteless tomato, in a sucky country, preparing to leave to the place of scribblers and their slaves.
Some say programming is an art not a science. Some may even claim to prove that by the lack of scientific theories to determine how to write good code or quantify the code quality.
ReplyDeleteBut if all software engineers will be declared artists and no one could tell when the "painting" is done... We'd be nowhere.
It's an art for the best, a job for the rest and managers like always "enable" things to happen (= add overhead most likely - they have a higher paid job to fill by doing little to nothing... ahem... coordination).
I'm pretty sure that some kind of control is necessary. But to raise it to this extent... it's brain-damaging.
ReplyDelete