thekua.com@work

I remember stepping into a heated discussion with two developers who just couldn’t agree whether or not they should be writing their code defensively. One of them argued they should always be checking for null, checking for illegal input and throw appropriate exceptions before doing anything with it. The other argued that they should not because of the amount of code that would add to every single method. I think I understood where they were both coming from and suggested that they were both correct though under different circumstances. One of them asked me to explain, and considering I see this argument resurfacing again here and here, I thought I’d post my thoughts.

Scenario A: Dealing with those outside of your circle of trust
Let’s say you’re working in Team A, developing an API for the greater public. It might be as big as a core platform development API, or an opensource library. Either way, it’s not possible to learn how everyone is going to use your API and not enough to simply document it because some people will not read all the documentation. Programming defensively helps consumers understand how your code was meant to called because there is no single way you can ensure your clients have the same understanding, regardless of the amount of documentation you put together. They lie outside of your sphere of influence. The longer the release cycles, the greater the risk someone might use your API in a way you hadn’t intended. This is the situation the authors of the .Net Framework Guideline worked under and as such you’ll see they’re emphasis on defensive programming. You don’t always have to do it in this situation, you’re just more likely to.

Scenario B: Dealing with those inside your sphere of influence
You might be working closely with another team, either in your organisation or in another one, writing an API for them to consume. Do you write your code defensively? I think it depends on how much influence you have. If you have enough influence that both parties understand the contract well, and your release cycles are reasonably fast, you may not have to. If you have long release cycles, or your relationship with the other team is more like the general public (you have no idea how they’re going to use your API), you may choose to program more defensively to provide faster feedback for your clients. I try to use this as the last resort when I’m in this particular situation.

Scenario C: Inside your own team
I rarely find good reasons to program defensively for code that I will ultimately write. It doesn’t really make sense for me to add in additional lines of code where I can easily test all the execution paths of the final code.

Conclusion
This advice is in constant practice. Even when you’re working under Scenario A, it’s only your external APIs that you are probably interested in programming defensively. Delegating to all other private or internal members will often be in the context of Scenario B or Scenario C. Remember the rule that ‘Context is King’, so ensure everyone understands that context before jumping to a particular conclusion about what you should or should not be programming defensively.

Comments(2)

I remember reading about the Cause, Made Visible and Not Related story on Esther Derby’s blog a while back. My biggest takeaway was that retrospectives aren’t normally the Cause of issues, instead creating Visibility into the issues already present. People constantly surprise me when they say that don’t like retrospectives because it doesn’t fix their issues. Guess what? Simply holding a retrospective won’t magically fix all your issues because it isn’t the Cause of them. Yet how do you go about fixing your issues if you don’t take the time to identify what issues you have, what impact they’re having and how you’re going to fix the true Cause?

Image taken from Dr Pat’s Flickr photostream under the Creative Commons licence.

Comments(0)

Maven only has 20 FAQs on its page here. I’ve been working with it on a project recently, and frankly I had plenty more than 20 to ask. Here’s my list of a few things that I hope will help people when they’re searching for answers not described well in the Maven documentation.

How do I get a plain file (*.txt) included into my deployment file (i.e. jar, war, ear)?
Maven’s default file structure looks like ${projectBase}/src/main. The compile target looks for production code under ${projectBase}/src/main/java. It looks for other files to include with your production deployment in ${projectBase}/src/main/resources. Adding your file to that directory will automatically include them in your deployment file.

When Maven downloads its dependencies, where does it store those files on a windows machine?
Look for files under C:\Documents and Settings\${userName}\.m2\repository.

Why doesn’t a feature from JDK5 or 6 work?
By default, Maven compiles against JDK1.3. Set the source and target JDK where you have your compile target:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <source>1.5</source>
        <target>1.5</target>
    </configuration>
</plugin>

How can I create a single deployment file with all dependent libraries merged?
Instead of using the maven-jar-plugin plugin, use the maven-assembly-plugin. Here’s an example

<plugin>
     <artifactId>maven-assembly-plugin</artifactId>
     <configuration>
          <descriptorRefs>
               <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>
          <archive>
               <manifest>
                    <mainClass>com.thekua.spikes.App</mainClass>
               </manifest>
          </archive>
     </configuration>
     <executions>
          <execution>
               <id>make-assembly</id>
               <phase>package</phase>
               <goals>
                    <goal>attached</goal>
               </goals>
          </execution>
     </executions>
</plugin>

Comments(0)

Excel 2007 is quite a horrible experience. Someone recently told me a story where apparently, Micro$oft said that it’s easier for new users to learn, yet would take three weeks of re-training for existing office users. Shame I fall into the latter crowd and not the former. Read on if you are wondering where your worksheets went and want to insert a new worksheet. (more…)

Comments(0)

What’s wrong with this: “Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one.”

How about? What are you talking mojo to me for? What is going wrong and how do I fix it?

Perhaps something like this would be a better error message: “Maven is looking for the pom.xml file and cannot find it. Maven assumes this file is in the directory you are running it from. If you are running Maven in a different directory, perhaps you might want to use the –file switch.”

Comments(0)

My last post triggered a few comments, with having a common goal for a team to rally around somehow also implied groupthink, and thus, Wisdom of the Crowds is a better alternative. I want to clarify a few things:

The point of the original post?
Organisations where I’ve seen them have successful delivery, they also had, what I would consider, true teams. People working together towards a common goal. I’ve also observed many other organisations struggling to deliver, and often, because of multi-project context switching, they had what I would describe as “groups of people” instead of a true team.

Not all teams have groupthink
When I think back to great teams I’ve worked on, the individuals complement each other strengths and, at least in my experience, respond better to unplanned events. Talking about the “taboo” topics is fine because everyone is already comfortable working with each other. I compare this experience to what I see around committees, newly formed teams, or even teams that remain unbalanced (due to a particularly strong member or something) where other participants are too polite, or don’t want to cause a commotion even though it may be the right thing to do.

Understandably, when Felix saw my diagram, he (rightly) feared groupthink. In my experience, I feel it is symptom of poor performing teams, and is more likely to happen with “groups of people” (think of all those traditional project managers who make a decision for the team!). I do acknowledge it can still happen in a high performing team.

I believe the trick to making this work is having a leader in the team that ensures that conflict is handled in a safe environment, not simply quashed, silenced or bullied away as these eventually lead to group think.

Wisdom of the crowds don’t necessarily mean all crowds are wise
When I see many groups of people, I don’t automatically see a lot of wisdom. It takes another step before you can benefit from wisdom of the crowds. Often it means asking the right question, the right amount of diversity, and a lot of independence to actually benefit from it. I see the right question the same as having the right goal shared amongst people. It doesn’t necessarily mean everyone is doing exactly the same thing to get there, it just means that everyone is pointing in the right direction.

An example: Brainstorming using sticky notes is one way that I’ve worked in that avoids groupthink and tries to harness the wisdom of crowds. In my last team, we used it to come up with different solutions to tackle a key design problem (note the shared goal!) We each wrote ideas down independently on sticky notes before presenting them to each other. We even spent some time investigating and proving out a number of solutions to gather some hard data about the pros and cons. What made it work was that we all understood what it was we were all trying to get to (the shared goal), not necessarily how we get there. I felt that this was an example of a real team, a situation where everyone was comfortable disagreeing with each other, and openly discussing each option. It certainly didn’t feel like a committee or a random collection of people. I can only imagine what the outcome would be if we did though.

Once again, your comments welcome.

Comments(3)

When I go into different organisations, I see many of the people doing the work (analysis, development and testing) split across multiple projects. In my experience there are plenty of reasons why this is just a bad idea, and probably the biggest one that I see is that the split priorities for an individual conflict with a model for ideal teamwork.

What does your organisation have more of? Teams or groups of people “working together”?

There’s a big difference between the two, particularly if your organisation is interested in tapping into the benefits of teams. Unfortunately most of the time organisations miss the mark.

How can you convert groups of people into teams?
Split priorities create natural conflicts between groups. A lot of management theory I’ve read describes how to get the most out of teams by rallying them towards a shared goal or set of goals. At the individual level, setting different goals for different people establishes a dynamic that, at some point, individuals’ priorities will conflict and without a broader shared goal, will go unresolved. Setting the same priority for everyone is, in effect, putting everyone into the same team. Leaving people split across multiple projects, is in effect, setting different sets of priorities for an individual.

Comments(9)

I’ve previously written an article for InfoQ about how agile coaches act when working with teams. For this particular entry, I want to investigate what jobs or roles you might consider trying to either focus on part-time or try full-time to develop the habits and skills necessary to be an even more effective agile coach.

At the XP2008 conference I spoke with both Liz Sedley and Rachel Davies, two other agile coaches, who ran a workshop about agile coaching. We talked about the different skills an agile coach might need and some of the duties they might perform. We talked about overlaps with other jobs and concluded that an agile coach may do some training, yet only being a trainer doesn’t make you an agile coach (there’s more to it). Below is a diagram that hopefully makes it clear some of the responsibilities that overlap with a number of other roles.

As you can see in the diagram above, an agile coach may do many of the things you see full time facilitators, full time trainers, and full time coaches do. Yet doing each of these roles by themselves without the real experience garnered from agile projects does not make them an agile coach.

Using this as a model for career development

Even though I just put this diagram together to help others visualise this model, this is exactly what I’ve been using to further improve my skills as an agile coach. More recently, I’ve been in the role of a full time coach and trainer both internally and externally, and especially fortunate to work closely with other full time trainers to benefit from their experience. That experience has given me a better understanding of how people learn and a broader set of techniques to draw upon when helping others understand the concepts and principles.

Earlier to that, my focus had been towards better facilitation practice, reading books about good facilitation skills, and eagerly applying this during the projects that I’ve worked on. This has been particularly useful in executing the Retrospective practice. Beyond that, I’ve been lucky enough to work on many different agile projects in a development role, benefiting from others’ experiences through observation.

I’d be keen to hear what other full time or part time roles other agile coaches have attempted for short amounts of time in order to develop the skills that will make them a better agile coach. Please leave a comment if you have a suggestion.

Comments(1)

George Ambler’s blog entry titled, “Agility Means Simple Things Done Well, Not Complex Things Done Fast“.

Comments(0)

Not much to update other than I’ve returned from Canada and have been busy running a couple of presentations around the place, most recently heading up to Manchester for a night to help Alex Scordellis out with the Manchester Geek Night he’s running regularly. I ran a session called The Agile Primer, essentially an introduction to agile methods. We had a great turn out and I particularly enjoyed the discussion that ensued both during the session and at the pub afterwards. It still seems that, at least in that one pub up north, they shut relatively early. My only regret about the trip was that I didn’t get to stay longer and see Manchester because the weather was so nice.

Yesterday I helped out an analyst group with their Master Class on Agile. Liz Keogh and I pair-presented on ThoughtWorks’ experiences and lessons learned with distributed development, titling the session Distributed Agile: An Oxymoron?. We then followed this up with the XP Lego Game that helped people keep awake after plenty of talking and a heavy lunch.

All the slides and resources, you can continue to find on my page of presentations and papers.

Comments(0)