thekua.com@work

If you happen to be unfortunate enough to stumble across “region”-ised C# code, use the following short cut keys to expand all in a file:

CTRL-M + CTRL-L

Give it a go! Or better yet, disable all code folding by default:

Text Editor -> C# -> Advanced. Uncheck “Enter outlining mode when files

Go to Text Editor->C#->Advanced. Under the “Outlining” section, uncheck the option labelled “Enter outlining mode when files open”.

Comments(0)

All of the tips I wrote a long time ago for speeding up Visual Studio 2005 still apply. I’ve found that the preferred replacement for Cool Commands is the Power Commands plugin that Microsoft now provides.

Comments(0)

Last time I wrote about the ORID (Objective, Reflective, Interpretive, Decisional) model for conversations. Software development is hard because not only do you have to deal with technical challenges, but there are so many opportunities for poor communication. Detecting when poor communication occurs is important, as it lets you ask questions and steer conversations back into a much more productive result. Here’s a classic conversation I hear on software teams all the time:

Person A: We’re going to use <tool/framework/library>
Person B: No! <tool/framework/library> sucks. We’re going to use <alternative tool/framework/library>

Note that both of these people have jumped to the Decisional stage of the conversation (i.e. What to do). I’m sure that individually, both people went through the model, yet didn’t attempt to step through together (or as a team) each of those stages. I’ve learned that it’s easy to jump to different conclusions (D) if you don’t share the same background.

Using the ORID model as a guide, here’s a much more effective way the people could have had that conversation:
Person A: I’ve noticed we write a lot of code that deals with files. (O)
Person B: I’ve noticed that as well. (O)
Person A: It makes me feel frustrated (R) because we spend less time doing interesting stuff (I)
Person B: I didn’t realise you were frustrated about it! I also notice we tend to have a lot of bugs in that area as well (I)
Person A: I’d like to use some <tool/framework/library> so that we can improve our productivity (D)
Person B: I definitely would like to as well.
Person A: I think <tool/framework/library> would work well
Person B: I’ve had bad experiences with <tool/framework/library> because it also has lots of bugs (I). I think <alternative tool/framework/library> might still do the job, and help you feel less frustrated. What do you think? (D)
Person A: Let’s give it a go.

The conversation may not still go in the same direction of agreement, however there is much more opportunity to discuss why one particular solution will fit the issues both parties are feeling. Without making those items explicit, the discussion becomes an argument about choosing one solution over another. With a shared understanding of how both people are feeling, there are many more opportunities to clarify what problems the solutions are trying to fix. In fact, the solution each party originally thought of may change as a result.

Comments(2)

Conway’s Law describes the observation of mirrored organisational structures in an application design. I’ve recently been reminded of some examples we see everyday where you see lots of defensive programming. Although you should see less defensive programming when working with internal groups, a lot of it immediately tells you about the lack of trust and collaboration between members of the same project.

Comments(1)

Arriving as someone who has to inherit a large existing codebase is often an intimidating exercise. Many agile practices in particular help you learn a number of the details, including the original XP metaphor, pair programming, test driven development, daily stand ups, and showcases. Many other valuable practices should also help including an excellent onboarding program, always available mentor(s), and an easy to set up environment.

We’ve been considering a number of techniques to learn as much about the system as possible. Here are just a few of the ones that spring to mind:

• Uncover all external dependencies – External dependencies and integration points are often killer spots for fast feedback loops, be they running local tests through an interface, or by just trying to deploy an application and see if they are live. Each dependency adds complexity to deployment, another point of failure, and possibly another communication bottleneck with parties outside. Some examples of external dependencies include specially licensed software or services, databases, file systems, other software applications, web services, REST services, and messaging queues or messaging buses.
• Validate your own understanding of the architecture – An architecture diagram is often useful when starting to navigate a codebase. The implementation of that architecture may not be as clear as a high level diagram, so it’s important to uncover the flow of a system. What we’ve found useful is building up a flow through the system using a specific example scenario to understand the interactions of classes as they fit into the architecture.
• Read through tests – If you’re lucky, your system will have plenty of tests. Start with the higher level ones that walkthrough system level interactions, delving into the more granular ones when it’s not necessarily clear.
• Try to write some automated tests – Try to test something in the system and you’ll suddenly discover you’re pulling a string that happens to be connected to everything else. You may learn what happens to be the most used (or abused) classes and where all the dependencies start to overlap.
• Generate diagrams using analysis tools – Consider different visualisations of code to understand how all the parts of the system fit together.
• Write down questions as you go (and get them answered) – Ask lots of questions after you’ve had some attempt at getting your own understanding. It will take a while to get the domain vocabulary and your questions will be more useful the more context you have.

Leave a comment if you have other strategies that you have found particularly useful. We’d certainly appreciate it right now.

Comments(1)

Last year, Esther Derby and Jean Tabaka shared a model at the 2008 Retrospective Facilitator’s Gathering that I now think about all the time. Esther Derby and Diana Larsen used it as the base model to describe how to run retrospectives. It also got me thinking how it mirrored different models described by other facilitation approaches, negotiations strategies and advice on how to give effective feedback. Apparently this originated in the book, The Art of Focused Conversation.

The base model starts with the acronym ORID that means:

• Objective – Focus on the facts, hard evidence data
• Reflective – Focus on how that made people feel or other associations
• Interpretive – Focus on the impact and significance
• Decisive – Focus on next steps.

I thought it’d be useful to share this model with a wider audience, and I keep forgetting what the “I” specifically stood for, so I’m putting here so I can find it later.

More on how to apply this later.

Comments(1)

Plans may be the direct result of progress but the inverse is rarely true.

Comments(0)