Part of this interview “Ivar Jacobson on UML, MDA, and the future of methodologies” where Mr Jacobson comments on main differences between software development methods based on explicit knowledge and those based on tacit knowledge lead me to thoughts I am willing to express in this post on knowledge within software development (methodology).
I am not going to elaborate on definitions here since there’s an excellent article “Convert tacit knowledge into explicit knowledge to ensure better application development” describing differences and co-relations between tacit and explicit knowledge. Please check both, interview and article before reading this since you will need some preliminary understanding about subject.
So, considering above thoughts of the Mr Jacobson and considering argument of Mr Kuhn on conversion process I must say that statement of Mr Jacobson on shortcomings of methodologies based on tacit knowledge was incomplete.
To quote Mr Jacobson on problems with methods based on tacit knowledge – “how do you teach that?” “how do you know what it is?” “(in a team with tacit knowledge) how do you get them to agree on what to do?” “how can you possibly grow that knowledge?”
Well, I have actually answers to those hypothetical questions:
“How do you teach that?” – well you don’t that’s the whole point you show and then show again until other people get the point
“how do you know what it is?” – again, you don’t but that’s OK since you don’t have to articulate it, just show
“(in a team with tacit knowledge) how do you get them to agree on what to do?” – to have a consensus all members must have either same (tacit) knowledge or there should be dominant expert who forces his tacit knowledge upon rest of the team. If this is not the case, getting agreement on what to do will turn out to be lengthy and unlikely productive process, but – result would be an answer to the next question.
“how can you possibly grow that knowledge?” – i say, same way you’d grow explicit knowledge – in a evolutionary way! How do you grow explicit knowledge in first place? To grow any method one will have to add new stuff and because its new there is no information about it within existing method.
To rephrase Mr Kuhn – invention itself is conversion or articulation of tacit knowledge through which it is converted into explicit knowledge. In other words to create explicit knowledge you NEED tacit knowledge in first place.
The conversion process described by Kuhn is looped tho, that is – as soon as you create explicit knowledge, you need tacit knowledge to evolve or re-define that explicit knowledge. New and better definition of explicit knowledge emerges after so called “revolutionary paradigm shift”. Users of this new knowledge start to gain new tacit knowledge immediately in the process of working with explicit knowledge and eventually put explicit knowledge under question thus sooner or later forcing next “revolutionary paradigm shift” and so on, and so forth.
I may be too bold stating that establishment of this cycle actually gave human kind that edge against other animal species by allowing to overcome shortcomings of evolving only with tacit knowledge (because its too slow). Evolution only with explicit knowledge would be even impossible (since It’s tangible. There’s no need to gain experience. It’s something that has been converted to a rule).
Ergo
Well, my conclusions are:
– tacit knowledge actually does the job of evolving things based on that knowledge
– explicit knowledge does the job of formalizing, explaining (learning) and distributing tacit knowledge
Today, only together they give evolution the speed we are used to, the speed we are not willing to give up. Projecting this on software development methodology is straight forward – only method that uses both types of knowledge has a chance of fast evolution.
Since, as far as I know, there is no method yet that would explicitly base itself on both knowledge types I am happy to say that we still got a lot of work to do and a lot of new things to invent 😀