+972 52-548-6969
Implementing Methodologies
time to read 2 min | 226 words
I am writing this in a bar in Malmo. Sitting with a bunch of guys and discussing software methodologies. I had an observation that I really feel that I should share.
Most software methodologies are making a lot of implicit assumptions. The most common implicit assumption is that the people working on the software are Good people. That is, people who care, know how and willing to do.
This work, quite well, in the early adopters phase, since most early adopters trend toward these set of qualities anyway. The problem is when the early adoption phase is over, and the methodologies hit the main stream. At this point, the implicit assumption about Good people no longer hold true.
Just to annoy Scott Bellware, here is a big problem that I can find with Lean just from the things that I heard about Lean from him. Toyota hires the top 2% of the engineers that they interview. A lot of the methodology assume a competent team, or at the very least, a competent chief engineer.
I don't think that I need to state that competency is not universal.
If your methodology assumes competence, and most of the methodologies that we (as in I and like minded people) would find favorable do assume competence, it is going to fail in the treches.
Comments
Are you seriously carrying your Air to bars with you now?
I agree. It is one thing for one developer to understand the gains from following a certain practice, but it is a completely different thing for that developer to make his colleagues understand the gain.
It can take a while for some people to understand the value of thorough unit testing, although it is my impression that most people can understand this. But stuff like TDD, IoC, SOLID and even continuous integration seem to be more difficult to grasp, and I don't think all developers will understand and/or accept it all. I have certainly experienced this by working with my own colleagues.
But I also think that if we give up on those colleagues, we are copping out. If we see ourselves as good software developers, we need to get better at passing on that learning we believe makes us good to people who might not seek out that learning by themselves and I think the notion of software apprentice could be really useful for this.
yes, you are right.
But have you ever seen a methodology that works with an incompetent team?
or put differently, have you ever seen an incompetent team succeed?
Even 'no brainer', obvious improvements that don't require learning investment can cause problems. I recently made a political mistake introducing CI to a codebase that is shared with developers from another company. They freaked out big time (despite agreeing to it in a meeting) and demanded that I remove it as It was 'nearly Christmas', so we must carry on using ad hoc builds from their developer machines to avoid problems.
The code they produce really is the most stereotypical late 90s vb6 voodoo stuff 'intValue as string = false' 800 line methods levels of horror. The worst of of is that they don't even know how bad they are, choosing to spin necessary basic improvements to process and technique as dangerous so they can stay in their comfort zone.
Mr ludd is still alive and well in the north on England and is working in IT
Comment preview