Sunday, 29 July 2012

Scala, Maven and Eclipse

You might be having trouble getting Scala IDE, Maven (m2e) and Eclipse to play nicely. In particular the More than one scala library found in the build path [...] At least one has an incompatible version. Please update the project build path so it contains only compatible scala libraries.

Try the following:
  1. Generate a scala project using the maven archetype scala-archetype-simple
  2. Edit the pom.xml with the following:
    • Change the scala.version to 2.9.2
    • Remove the unit testing dependencies (add the ones you need back later once you have the other stuff working - the default versions won't be compatible with 2.9.2)
    • Change the maven-surefire-plugin to 2.12
  3. Remove the sample test classes in src/test/scala/sample
  4. Import the maven project into eclipse: Package Explorer -> Import... -> Existing Maven Projects
This should now give you a mavenised Scala project loaded into Eclipse. If you have trouble with eclipse not updating with your pom changes, delete the project, clear out the eclipse stuff from the project dir (.project, .settings, .cache, etc) then re-import the maven project.

Also note that I'm using:

Saturday, 28 July 2012

Give your people time to innovate



Developers who are too busy to experiment are wasted talent. Software developers are smart people who need to be creative to be good at their jobs. In all but the most lax environments, team members will have their work set out for them. Even in Agile environments, there might be flexibility in who does what work and developers will be involved in the work estimation process. Ultimately, it is management and customers who decide what work is done.

Google has made the concept of 20% time famous. However, 3M have been encouraging their employees to experiment for 15% of their time since 1948:

"[..] workers often use 15 percent time to pursue something they discovered through the usual course of work but didn't have time to follow up on." Kaomi Goetz - www.fastcodesign.com

The idea is very simple. Give your teams a little slack so that they can try out new things. For example, a programmer might want to try out a new library, learn a new language or build an app. There are some solid benefits:
  • They can work on an idea that they think will be great, but would never be able to convince management without a prototype. Products like Google Mail and the Post-It note came out of these kinds of schemes.
  • Fix something in the product won't ever be a high priority, but these kinds of things tend to add quality to the product over time.
  • On the smaller scale improvements to processes and smaller innovations that can be added to existing products.
  • It is great motivation for employees. All projects will have periods of grind where developers are just cranking out repetitive work. A bit of a break when they can let their hair down does wonders for morale.
  • It's a great form of training. No matter what people work on in this time, they'll be learning while doing it.
Ok, so assuming that you're now convinced, how would you implement a scheme like this? Mike Cannon-Brookes of Atlassian says:

"You see, while everyone knows about Google’s 20% time and we’ve heard about all the neat products born from it (Google News, GMail etc) – we’ve found it extremely difficult to get any hard facts about how it actually works in practice."

It will ultimately depend on your organisation. I think the key is to keep it as open as possible. Any constraints on the developers are going to limit any possibly innovation. However, a few constraints will help keep everyone's goals aligned:

"Self-organizing systems are able to create their own rules. All is needed for such a system to work is a set of simple constraints, sometimes called a boundary. It is important for managers to tune these constraints, and not to try and design all the rules. This means the job of a manager is to manage the system, and not the people in it." Management 3.0 - Jurgen Appelo

For example:
  • Your project should be something that would improve the company
  • Your project should have short, achievable goals
  • Your project must be visible to everyone
The first point is designed to steer people to work on something relevant to the company but without limiting them so much that they play it safe.

The typical scheme will be between 10% - 20% of the employee's time. Any less and they won't have time to produce anything of substance, any more and it will interfere with their jobs. However, this is still not much time, so it's important to make sure people aren't being too ambitious and setting themselves unachievable goals (e.g. write an operating system in 4 hours). This also helps with the other two goals. 

Lastly, people should be talking about what they are working on. This is important for stakeholders to see that people aren't just wasting time. More importantly, however, it means that people are sharing ideas which is going to generate more ideas and collaboration. A wiki and small demos might be a nice way to kick start this.

So why not try it and see what happens. Friday afternoons are typically productivity sinks anyway. Why not use that slow time to stir things up a bit?

Friday, 20 July 2012

Teaching TDD


I've been evangelising TDD at work and have been quite surprised by the how it has been taken up. In general, people are excited to learn about TDD and there was an excellent turnout to talks a colleague and I have given. We ran through the full test driven cycle: 
  1. Write a test
  2. Watch it fail to compile
  3. Fix the compile errors
  4. Run the test and watch it fail
  5. Write just enough code to make the test pass
  6. Watch the test pass
  7. Refactor
  8. Go to step 1
We demonstrated each one of these steps with 3 or 4 unit tests for an example class. However, no matter how much I repeat that you shouldn't write code before a test and that you should only write enough code to make your test pass, people struggle to get their heads around that idea. I still often come across people who are trying to learn TDD, but are not following this pattern.

I was prompted to start running the mini TDD courses when I saw a piece of code a junior member of my team was working on. He was still not used to the idea of writing tests first, so I sat with him and helped him write a bit of code in the TDD style. While he coded in front of me, I was able to point out when he'd skipped too far ahead and had written code that he didn't have a test for yet and it was only after a few round of this that he finally got what TDD was all about. 

I think that a practical one-on-one session like this is the only way to really show someone how to do TDD. Sit with them and have them start writing code and just gently nudge them when they've skipped a step. I've done this a couple of times now and it only takes a couple of tests before it sinks in.