The intersection of technology and leadership
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”.
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.
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.
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.
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:
Leave a comment if you have other strategies that you have found particularly useful. We’d certainly appreciate it right now.
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:
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.
One of the biggest divides you need to cross, even on agile teams, is the chasm between testers and developers. By the nature of their different roles there will always be tension with developers focusing on creation, change, and construction, and testers focusing on breaking, destructive, and exposing questionable system behaviours. It’s essential that both organisations and, in particular, individuals realise what they can do to ensure this tension doesn’t dissolve into an exclusively confrontational relationship.
Photo taken from Sephiroty’s Flickr stream under the Creative Commons licence
Recently, a new QA person highlighted this very issue for me. I’d finished some functionality with my pair and the QA had been testing it after we declared it ready to test. They came along to my desk and said, “I’ve found some defects with your code.” Internally I winced as I noticed myself wanting to say, “There’s nothing wrong with my code.” It got me thinking about why.
Evaluating people puts them on the defensive
Just as giving effective feedback should focus on behaviour, poor feedback makes a person feel criticised. When the QA said that there are some “defects”, it implied a broken state that you had to fix it. Made worse is the way that they said it made it feel like they were blaming you, and it’s very hard not to feel defensive in a situation like this. A very natural outcome is to pretty much deny the “evaluation” which I’m sure anyone in our industry would have witnessed at least once.
Avoid terms like “defect”, “broken”, “bugs”
One of the biggest differences working with agile testers versus testers who come from traditional backgrounds is the terms that they use. Traditional testers constantly use the words above. Agile testers focus on discussing the behaviour of the system and what expected behaviour they would see. They only use the words above once they have agreement on both of the both the current and expected behaviours. I definitely recommend you do not start a conversation with the words above as they all carry some connotation of “evaluation” and I’m yet to meet someone who truly feels comfortable being “evaluated”
Focus on Effective Feedback
Effective feedback follows a neat and simple pattern:
Testers should use a similar series of questions (in order):
Apply the guideline above and watch the collaboration improve!
Most organisations emphasise repeating the “process”, serving to distract from the real goal – repeating “success”. You need a certain amount of flexibility and adaptability in your process because you never work in the same environment twice.
This does not mean you do not use things that have worked well for you in the past. It means you should be prepared to change them if you can do it better.
Cockburn talks about waterfall development being a poor strategy for learning so what do agile methods give us that allows us to learn better?
One thing I constantly remind myself is that we tend to be write pretty poor code the first time we do it. Unfortunately most people also write a lot of first time code, check it in and move on. Refactoring is one strategy that lets you learn about how to change the code better and is often one that most people reach for.
One practice that I’ve been doing more and more frequently is Do things multiple times. Sounds horrific right? Sounds like a huge waste of time? I think it can be if you don’t learn anything from it. Therefore in order to maximise learning, I think you need to also master a number of supporting practices like Use Version Control, Check in Frequently, Small Commits, and Automated Tests.
Here’s an example of this practice in action:
I’d seen some spike code that had somehow made it’s way into the codebase. It had minimal test coverage, had many more lines of code than I was comfortable with and involved many different classes all slightly dependent on each other in some way. I wanted to refactor it but didn’t really know what the best way of doing it was. I retrofitted some tests around it, running code coverage to get a good understanding about what areas I was now more comfortable changing. I ran the build, got the green light and checked in.
I applied some small refactorings, ran the tests and watched everything spectacularly break. I looked back at what I did and started to understand some of the relationships better. I rolled everything back, this time trying something slightly different, before running the tests again. Things broke in a slightly different way and I spent a little bit of time understanding what happened this time. I rolled things back again and then tried a different approach. I want to emphasise that the timeframe for this is about fifteen or twenty minutes.
Compare it to other approaches I see quite frequently, where someone sets out to do something, gets into a broken situation, finds something else to fix and ends up working on multiple things at once. They keep patching stuff to get the tests to pass again, and once they do, check in and move on.
You should only Do things multiple times if you can Check in Frequently, execute Small Commits (therefore you lose very little when you rollback) and have Automated Tests so you know if you broke anything.
Repeating something is only waste if you don’t learn anything from it.
© 2024 patkua@work
Theme by Anders Noren — Up ↑
Recent Comments