It's kinda embarassing, but I've just recently read Tom DeMarco's & Tim Lister's "Peopleware" - the book I believe I (and everyone else, who's involved in working with other people on software development) should have read yeaaars ago. Anyway, I've just recently filled the gap and I simply couldn't resist making a lot of notes - some of them I've quoted on Twitter, some I keep for some other purpose. One of the excerpts I really, really liked is the one about the difference between Methodology and methodology - and that's the topic I'd like to write about today ...
Not just because I've found it amusing to read, but because it perfectly describes some real-life situations I keep encountering every now and then in my professional career.
How does "Methodology" differ from "methodology"?
According to DeMarco & Lister:
-
As most of the organizations are only as good as people they hire and it's hard (and/or expensive) to get top-notch people on-board, these organization walk this around by staffing lower quality people and giving them "Methodology".
-
What's the "Methodology"? Let me quote the original authors:
fat book that specifies in detail exactly what steps to take at any time, regardless of who's doing the work, regardless of when or when.
- Is it actually that bad? What does it really mean? I don't think I can summarize that better than DeMarco & Lister, so let me quote them again:
The people who write the Methodology are smart. The people who carry it out can be dumb. They never have to turn their brains to the ON position. All they do is start on page one and follow the Yellow Brick Road, like happy little Munchkins (...) The Methodology makes all the decisions; the people make none.
Amen. Hopefull you get that. But we're not there yet. Here comes the best part ...
- There's nothing bad in doing work in an organized & structured way, to follow some kind of best practice or guideline. But only if this work is performed by people who:
- do understand what they do (and how it will help to achieve the final goal)
- do understand why they do that (for every activity they perform)
- do understand what can happen, if they won't do what they do
That's methodology (with a lowercase m).
- Methodology on the other hand (again, time to let DeMarco and Lister do their talk) ...
... is an attempt to centralize thinking. All meaningful decisions are made by the Methodology builders, not by staff assigned to do the work.
Voila. Here we got it.
So what? Why should we care?
If I had to list down all the negative effects of using the Methodology, this blog post would have be tens of thousands characters long. Let me just go through the major points:
Ivory Tower syndrome
Here you go, get this book and follow the path that's written. This is The Official Way. This is The Policy. This is How Things Are Supposed To Happen."
Yes. The evangelion of stupidity. No-one cares, if it really applies to your case. No-one is able to even do such an analysis (question the Methodology? Never!). Just-do-it-that-way. If your case / project / scenario doesn't fit it really, there's no other option but to bend your case / project / ... Squish it into this rigid frame and keep the hopes high that it doesn't break.
Idiots with the book
Yes, we don't have people who actually did that before or at least have any theoretical knowledge about that. But you know what? Maybe you could write them down a short description of what to do or maybe there's an article on company Wiki about that?
Make the pile of scripts any idiot can execute, stick with 80-20 Pareto rule and collect the cash for service. Because the major factor of success is the procedure itself, it's the very one thing that was successfully used one a similar project in Ecuador five years ago. Well, the case is a bit different: it's not about Java, but about JavaScript; 5 years is rather long and in the end that project has failed ... - but you know, it seems close & good enough.
Generic vs Experts
What's the point in investing time & money in people to make them experts - they may leave, get bored or we may have assign them to another project anyway. Let's invest in Methodology: it won't betray us, it won't leave, we can apply it as frequently and as widely as we want!
All we need is brain-washed people with broken work/life balance -> we will convince them they are awesome, make them endlessly execute the Methodology and compensate the lack of thinking and agility with overtime and working weekends.
Sounds like a plan.
Anyone mentioned motivation?
Or self-development? Or killing all kinds of creativity? Not yet?
Methodology makes people stop thinking. Kills any joy they had in performing work. They don't actually achieve nothing - it's Methodology that eventually does and it could be just as well executed by monkeys.
This way people never get the sense of accomplishment, they don't feel ownership, they are not proud of they work. Every days is like a day before, there's no true progress in themselves - well, they may have a progress in salary and position, but do their competencies grow? In any way?
The Cult of Knowledge
Methodologies are abominations. Develop your own methodology, based on what you (and your team-mates) know:
- Think on your own. That's what the round thing on your neck is for.
- Learn & self-develop. Continuously. Every freaking day.
- Question and criticize. But stay absolutely & unconditionally constructive.
- Both ask for and give feedback. Listen to what people say, benefit from the joint power of the team.
- Use all kinds of accessible knowledge as a foundation / reference, but not by brainlessly following the recipes.
