joker.iki.fi

I’ve been thinking lately of a problem that constantly seems to hit a lot of IT projects (and probably other projects) in the face. Basically, how to make the basic assumptions and done decisions most efficiently known throughout the team.

For example, if the lead developer or architect decides that a component called “engine” needs to do only thing A and B, nothing else, and he thinks that if anyone, ever, wants it to make C, they always need to understand the original rational for limiting the functionality to A and B, before making the decision to add C.

Problems like this can become tedious in larger organizations because many people only typically know that the “engine” exists, but nothing else. Without knowing the context and basic assumptions made when the original decision to keep the functionality to the bare minimum, that is, only to have A and B in the engine, many people waste a lot of time and effort to design stuff without complete information.

Clearly, traditional approach, meaning documentation and learning, is quite slow and inefficient. Worse yet, collective documentation and collective learning are even slower. People constantly are misaligned with their documentation and with the stuff they have learned.

Nevertheless, I think I have found out at least few items that can make this better and I hopefully can pursue them in the near future. Please let me know if you are interested in this topic, I’m surely going to need help.