Communication and Context

What about it? We all know that communication is important and most of us also know that the context of where or what the communication is about is just as important.

Consider some of the pictures i took while in China. They show a will to communicate with you as an english speaker, but they do not always make sense. Anyway here are a few of them:


The next one is harder to understand the meaning of.. Mingtien means tomorrow, so maybe they mean tomorrows language café? or language coffee?




Think about the context when you communicate with someone. They might not understand what you are trying to communicate even though they understand the language.

Workshop: Legacy Code

It's true. We got it! We got legacy code..

To best describe legacy code I turn to one of the guru's on the subject, Michael Feathers:

[After all, there is an emotionally neutral definition of "legacy code." Legacy code is code from the past, maintained because it works. But, for people who deal with it day in and day out "legacy code" is a pandora's box: sleepless nights and anxious days poring through bad structure, code that works in some incomprehensible way, days adding features with no way of estimating how long it will take. The age of the code has nothing to do with it. People are writing legacy code right now, maybe on your project.

The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests.] ( full article and book )

We now have more than 180 000 lines of java code in my project. To me that is a lot of code. How can you have knowledge of the code to safely say that your change will not break any existing functionality? You can't!

There are many reasons to why you can't know for sure. Let me give you an example. One of the classes is almost 10 000 lines long and has methods that contains more than 500 lines of code. If we get a bug report and go in to that class to change something you can be sure that there is something in there waiting for you to mess it up. The class is impossible to change and it will take forever to fix this bug. And by fixing the bug you may actually introduce another , because someone was expecting that specific value in another part of the application.

The reason for expecting the bugged value can be many, but you can't know for sure if it will break something. Without a test, we can never know if that other functionality break when we change something.

Even with tests you can't be sure not to break anything. But at least your tests will lower the risk of not finding the bug you created with your change.


The tests help us have actual knowledge of the application. Not only can we read the tests, but we can actually get feedback from them when we do something to the code. This helps us to know more of the dependencies and the relations in the code. It helps us to understand the code better. But when you have 180 000 lines of code, do you really want to add another 100 000 in tests? No. But I do want to have tests around the changes i make and take small steps to create a safer place to work. Because it is fear that keeps us from attacking this monster class with our refactoring and our changes. Get rid of your fear by learning more about the code with tests.

In this spirit we have scheduled a small workshop for tomorrow to handle that fear. We will delete unused code and we will write tests for the code we are moving out of one of our biggest classes. We will discuss and learn about our code. With this knowledge of how to handle legacy code I hope that we will conquer our fear of changing code in horrible places.

This is knowledge in action!

Code review: increased quality and knowledge sharing

In my earlier post "Make it better" I said we were starting with a more TDD similar approach. We have tried this now for more than a month. We have tried writing tests first, but this seem to be a futile attempt. Arguments used are "I tried, but it took too much time to make the test" and "It is too difficult to make the test and it was only a small change in the code". To these arguments I can say that they are true in our case. Much of our legacy businesslogic has been placed in beans which in our case are difficult to write tests for. Hopefully we will be able to make more tests totally new businesslogic rather than trying to make it for the old code.

This said, I would say that we have in this process learned a lot about our own code and its limitations. Placing the business logic in beans is not good for the ability to test the code. We will try not to blindly do as the one before us did. I figured a way to try to compensate for the lack of writing the tests and introduced mandatory code review before any code can be checked in to the subversion repository. This forces the developer to argument and discuss the code before it become a part of the solution. It gives the developer another perspective and thus enable both the sharing of knowledge and an increase of quality. As in TDD the idea is that one would think differently before coding because we write the test first, we in this case do the code review after the coding but still enable the developer to get comments on both the code and its quality.

At the last xp & agile meetup in oslo we had Robert C. Martin (uncle Bob) present his thoughts on craftmanship and ethics where he mentioned that if we checked in code that was just a little bit cleaner and better than when we checked out we would eventually increase the quality of the code. The code review is a good incentive for this practice.

To quote uncle Bob: "Never check in bad code!"

Management Style

My previous post about Team Learning put requirements on the management. How can one manage people that know the job better than you or even work in their own way.

Management style is often influenced by organisational structure and reflects in what way the workers are coordinated. On the note of managing people Drucker (1999) mentions “that one does not ’manage’ people, but the task is to lead people.” And the goal is to make the specific strengths and knowledge productive of each individual. The more skilled and proficient a worker is in his work, the harder it is to manage this activity according to traditional management methods. A direct supervision approach requires that the supervisor have more knowledge or is more skilled than the worker to be able to know what the worker is supposed to be doing to get the wanted result. Due to the mentioned change towards more knowledge work in organisations today, Drucker claim that one does not need supervisors(13), but a leader –or put in terms of today- a coach(14).

Both Drucker (1999) and Wenger (2004) describes that their view of knowledge management begins with managing oneself as a knowledge worker. Take an active role towards your own learning and increase of knowledge. Peter Senge (1992) sees managing oneself as personal mastery, and by this meaning to developing one’s own proficiency. “Personal mastery is likened to be a lifelong journey with no ultimate destination.” He tells us that such a journey consists of processes whereby “a person continually clarifies and deepens personal vision, focuses energy on it, develops patience in seeking it, and in this way apparently increasingly views reality objectively.” This ownership and involvement leads people to do positive things towards achieving personal vision. Further personal vision is described as a calling of intrinsic desires, not a purpose to pursue. Senge claims as result, “People hold a sacred view of work because work now is valued for itself, rather than posing a chore that needs to be done as a means to some other end.“

People with high personal mastery “tend to be committed and exude initiative, have a broader and deeper sense of responsibility” in their work, and as Senge claims of key importance, they learn faster. This gives strength to the belief that answers to organisational inefficiencies lies not only in technology. Technology has often been seen as solution to efficiency and automation of traditional repetitive tasks. Furthermore information technology has enabled new ways of communicating and changed many of the traditional crafts and professions.

*13: Mintzberg (1983) claim that direct supervision requires close personal contact between manager and the worker, with the result that there is some limit to the number workers any one manager can supervise.
*14: Coaching has been used in sports and has become increasingly used as a management style in business the recent years. More on coaching see: http://en.wikipedia.org/wiki/Coaching

Team Learning

The previous post trigged a wish to share some excerpts from my master thesis with you!

In many organisations today, people are organised in groups to perform specific task. These groups are often called teams. The team can contain knowledge workers that acquire, generate and share knowledge. They work and learn together. Senge (1992) calls this team learning. Flood (1999) claims that often the aim of team learning is to achieve alignment in people’s thoughts and energies. This brings us back to the notion of mental models and that the mentioned alignment in thought is a shared mental model, or at least a similar mental model with common elements or schemata. If we have people that work with the same tasks within a similar context it could be that they have in some sense similar mental models regarding the task, thus a common understanding (Senge, 1992). Davenport and Prusak (1998) mention that without a common understanding of terms, knowledge sharing might not occur. Sometimes multiple and contradictory meanings for fundamental terms exists in many organisations and create barriers to consolidate information and knowledge. In support of this, Senge (1992) claims that discussion and dialogue are the most important practises in a team. He argues that discussion and dialogue are necessary counterparts in a quest for consensus. This consensus can be seen as alignment in the mental models between the knowledge workers.

Davenport and Prusak (1998) notes that the traditional management attitude is “Stop talking and get to work!”, while the advice to a knowledge worker should be “Start talking and get to work!”. This communication and alignment in energy and thought can result in what some organisations call best practices, where people learn from each-others’ success. The sharing does not only occur within the group, but it also influences other groups in the organisation, meaning the groups are not disclosed to influence from the outside. Team learning and knowledge sharing within a team enables us to act with today’s knowledge instead.

Another perspective posed along the same lines is to understand tacit knowledge sharing in a team, as people “following rules by being members of communities, with the disposition to reciprocally adjust our use of signs to that of the rest of the community” (Gerrans, 2005). This means that a community has its own rules and we act accordingly.

Interesting Answers

I have been quite busy at work the last week, but I did ask some questions..

And it seems that most questions can be asked without starting any problems for yourself or put you in a bad position. At least that was my experience during last week at work. The question opens for a dialog and create social relations between the people involved. I asked the questions because I where interested in the answers. This dialog has showed me perspectives from another part of the organisation and it has even influenced that part of the organisation to think a little different (at least it feels that way). A difference in perspective is natural, but with dialog we are able to direct the perspectives and the mental model of both parts involved towards a common one or something you can call an agreement. Or at the very least an understanding of each others viewpoints.

It reminds me of a motto I have: "If you do not tell the person what you think is wrong, how can that person do anything about it?" This meaning that if a person is not aware of his "wrong" behaviour, it will stay that way for a long time. If we have a dialog and talk about the issue we might both gain an understanding of why this behaviour is wrong. It might also be that it is right for him and wrong for you, but from knowing his perspective you can understand his actions.

I will end the post with a few words from Davenport and Prusak (1998), "Start talking and get to work!" (instead of the traditional "Stop talking and get to work!")