Since the previous post, I've reading up more on the devops movement and found a few nice pieces, particularly Graham Bleach on internal borders.

Thinking about borders within operations departments, I'm reminded of a recent client who operated with a mind-blowing number of siloed operations teams.  Coming at it from the development side, working through a problem with the operations staff was like exploring a never-ending labyrinth of teams.  Every time I probed a little deeper, my contact would defer responsibility to another mysterious team, usually located somewhere distant, that owned a slightly lower level of the stack.  Once I tracked down a real person in the mysterious team, the same thing would happen again, and I would be left searching for another distant team.  It seemed like I would never actually get to the real hardware.  An unforeseen consequence of virtualization is that it allows someone to declare themselves in charge of a Virtual Machine, but not in charge of the host or guest operating systems nor the hardware itself - staggeringly unhelpful.

The genius of these extremely-finely-sliced organisations is that they provide innumerable cracks down which responsibility, ownership and useful work can fall.  If a team has a sufficiently narrow focus, it is almost certain that no problem will ever occur that falls cleanly within its boundaries, so there is no responsibility at all - a manager's dream.

One thing that encourages me a little bit is a recent trend for counting the number "engineers" in an organisation.  I think all technical staff are counted in this metric, though I'm not sure whether people are including managers and other IT staff who might not be hands on.  In his QCon talk, Aditya Agarwal was very proud of Facebook's metric of 1.1 million users per engineer, while Andres Kütt was similarly proud of Skype's 600,000 users per employee.  Note that Facebook is very open about its number of engineers but secretive about its number of employees - I have no idea why.  I think counting the total number of technical staff is useful because helps people look at the broader cost of running software - not just development or just operations.  Also, I hope in the long term these kinds of metrics will highlight the painful inefficiency of silos and barriers.

I'm watching Michael Nygard's talk in the devops track at QCon.  This is my first taste of the devops movement and it's certainly something I like the look of.  I'm really struck by his assertion that we don't need a division between development and operations, but crucially he isn't saying that everyone needs the same skills - we will still have specialists.

I'm struck that this idea of bringing people together into a single team, while still maintaining specialisation, comes up a lot in the software world.  Some examples:

• We always try to have a single User Story implemented by a single team.  There may be different specialist skills required to implement a single feature, but all those skills should be in the same team and the people should work together; we don't want a "back end" team and a "front end" team.
• I'm frequently explaining to clients the value of having QA specialists integrated within a development team.
• More recently, with Pat Kua, I've been arguing for the integration of performance testing into the development team.

Having a single team has all sorts of implications.  I'm particularly keen on having a single backlog of work, even if not everybody has the skills to pull from that backlog.  Most importantly, a single team stands a better chance of having a single goal than do multiple teams.

Why are specialist teams so common in software?  My intuition is that it's a social phenomenon that people with similar skills and interests tend to congregate, and like working together.  Finding an effective mechanism to counteract this force, while still maintaining high-skill and specialisation, seems like a Social Technology (in Malcolm Gladwell's terminology) that organisations will need to acquire to be successful.

Domain Knowledge

QA

Usability

Polyglot

Value Driven

A People Person

Facilitation

Has "other" interests

Understands that technology isn't important

Alan Atlas has a recent blog post where he discusses agile, lean and scrum and suggests that you can't truly achieve agility unless your company is fully committed to it which differs slightly from my experiences.

Alan makes a valid point that we're not really following an approach just because we use all the practices:

Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.”

It's quite easy to put our work up on a story wall, run a daily standup and unit test our code and not really get the full benefit that those practices are supposed to give us.

As I've mentioned before though I think it is part of the learning process that we start out focusing on practices and not principles.

However, at some stage we need to start thinking for ourselves about the value those are giving and making adjustments to them if we're not seeing much value i.e. we need to look beyond the practice and to the principle or outcome that we are trying to achieve by using that practice.

The part of the post which is different to my experiences is this bit:

So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all.

I haven't heard conversations like this before but I think it is still possible to deliver software in a team working in an 'agile' way even if the rest of the organisation which that team operates in follows a different approach.

It won't be as smooth sailing as if the whole organisation buys into the lean/agile approach and there will still be some reporting and bureaucracy that you need to deal with but it's not a lost cause.

My colleague Lindy Stephens and a couple of others covered some of the issues around project governance in the enterprise in a ThoughtWorks QTB in Sydney last year. The slides from that presentation are available on slideshare.

If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.

Even if an organisation decides that it wants to be agile I think it still takes time to get used to the approach and it always seems to take a few successful deliveries to see that some of the worries that heavy weight processes and paperwork try to protect you against are not necessarily valid.

I've spent a lot of time being indignant that people didn't buy into the agile approach but the more I spend time in different organisations the more it becomes clear that even for the people with the best intentions in wanting to learn this approach it will still take time to get there.

I'm coming to the conclusion that it's a good thing that people have some level of skepticism because it forces you to really understand why an agile approach is more effective and then try and persuade other people of that.

It's also helpful to note that it makes sense to vary our approach depending on the context that we're operating in. For example if the team is distributed across different cities then we might have more written documentation than with a co-located team.

It's very rare that an organisation or group of people will just 'get it' straight away – in many ways it's quite an iterative/incremental journey.

Why should you be a trainer?

After being thoroughly impressed by the training that I received when I joined ThoughtWorks I was driven to become a trainer myself. I did that in 2008 (yes it’s already been that long) and am a different person professionally since then.

I am documenting my experiences for future reference as a mulitpost on Training. As I continue posting the topics on the list here will become active. Maybe as you read it will excite you to be a trainer too.

1. Preparation
   1. Preparing to be a trainer
   2. Preparing the Venue
2. Training to be a Trainer
   1. Science of Learning
   2. Cognition
   3. Psychology of a trainee/student/learner
   4. Training tools
   5. Imaginative use of training tools to suit trainee/trainer/class
   6. Studying the material
   7. Suiting the training material to your style and needs
   8. Dry runs
3. Delivering as a Trainer
   1. Preparing for the session
      1. Seating
      2. Be ready with the accessories for the session
      3. Prepare the material
   2. How to present yourself and still be yourself
   3. Finishing up the day
   4. Coaching/Mentoring/One-on-one training
4. Feedback – Desiging training
   1. Updating session content
   2. Updating training style
   3. Updating training schedule
   4. Updating training theme
   5. Adding new content
   6. Applying what you learnt as a trainer to your profession

I’ve been working for the last 5 months on build & deploy type projects. Both have been using Maven. I had started off convinced that it was pure evil. Many colleagues claim there is no place for it. I don’t know if I am convinced. Being with a central build and deploy team, responsible for making sure that up to 20 separate projects can be built and deployed to multiple environments, at differing schedules, Maven has made part of this pretty simple. Many arguments I hear seem very single project focused. They also seem very focused on only open-source dependencies. They also argue that they can manage their dependencies better by themselves, but theres the rub, “Themselves“. With 20 projects possibly managing themselves, and each having to share some environments, and all having to exist together as a product, that would be chaos. As my current client has observed.

Maven has been working (albeit with some pain). I do agree that a better way needs to be figured out and implemented, but I am not loosing any sleep about it.

My colleague John Hume wrote an interesting post about his experience with the 'const' keyword in ActionScript where he describes the problems with trying to capture a loop variable in a closure and then evaluating it later on in the code.

Since ActionScript and JavaScript are both dialects of ECMAscript, this is a problem in JavaScript as well, and is due to the fact that variables in JavaScript have function scope rather than block scope which is the case in many other languages.

This problem would tend to reveal itself in code where we try to capture a loop variable in an anonymous function and use it later on, like so:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
       x[i] = function() { return i; }
    }
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

We might expect that to print the sequence of numbers 0-9 on the screen but what we actually get is '10′ printed 10 times.

There are a couple of things that I initially found strange about this:

1. Why doesn't it print out the numbers 0-9?
2. Given that it doesn't do that why does it print out '10′ 10 times instead of '9′ 10 times?

The answer to the first question is that 'i' gets assigned a new value on each iteration of the loop and we don't evaluate 'i' until we evaluate the anonymous function on line 11.

The value when we do evaluate it would be the last value that it was set to by the loop which in this case that would be '10′ because that's the value that 'i' has to be in order for the loop to terminate.

This is actually a problem in C# as well – the following code will output '10′ 10 times as well:

[Test]
public void ClosureOnTheSameValue()
{
    var values = new List<Func<int>>();
    for(int i=0; i < 10; i++)
    {
        values.Add(() => i);
    }
 
    foreach (var value in values)
    {
        Console.WriteLine(value());
    }
}

Again we capture 'i' inside a closure and since we only evaluate that value when it's actually used it will always refer to the last value that 'i' was set to which in this case means that it will always output a value of 10.

To fix this in C# we could just create a temporary variable – something which Resharper will actually suggest to us:

[Test]
public void ClosureOnDifferentValue()
{
    var values = new List<Func<int>>();
    for(int i=0; i < 10; i++)
    {
        var idash = i;
        values.Add(() => idash);
    }
 
    foreach (var value in values)
    {
        Console.WriteLine(value());
    }
}

This works in C# because variables have block scope which means that we have a new version of 'idash' for each of the functions that we add to the 'values' collection.

Sadly the same trick doesn't work in JavaScript because variables have function scope in Javascript:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
       var idash = i;
       x[i] = function() { return idash; }
    }
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

The 'idash' temporary variable that we created to try and solve the problem gets assigned a new value in each iteration of the loop because that variable is only declared once for the whole function.

The code above could be written like this to make that clearer:

function getValues() {
    var x = new Array();
    var idash;
 
    for(var i=0; i < 10; i++) {
       idash = i;
       x[i] = function() { return idash; }
    }
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

As John points out:

Here's something I either never knew or at some point forgot about JavaScript: variables are lexically scoped, but only function bodies introduce new lexical scopes.

In this case we actually end up printing '9′ 10 times because that's the maximum value that gets assigned to 'idash'.

One solution is to create a temporary variable inside an anonymous function that we execute immediately, like this:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
        (function() {
            var idash = i;
            x[i] = function() { return idash; } })();
    }
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

Now 'idash' is scoped inside the anonymous function and we therefore end up with a new value each time like we want.

Raph pointed out that we could achieve the same thing in a simpler way with the following code:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) (function(i) {
        x[i] = function() { return i; };
    })(i);
    return x;
};
 
var values = getValues();
for(var j=0; j < values.length; j++) {
    console.log(values[j]());
}

Here we define a for loop with just a single statement so we can lose the '{}' and just call an anonymous function passing in 'i'.

Of course this example is truly contrived but I wanted to pick something simple enough that I could try and follow exactly how it worked.

I'm not entirely sure of the terminology around closures and scoping so if I've described anything incorrectly then please correct me!

For a while now I’ve been flying the flag for using a post-redirect-get design pattern when writing web applications. In my opinion the current crop of web frameworks still make it very easy to do the “bad” thing since to do PRG properly you need to think what kind of an interaction you want with users and not cop out saying its technically very difficult in <insert framework here>. If you resort to ActiveX controls, popups without navigation bars and/or weird javascript hacks to stop users from clicking refresh or back buttons then perhaps you should have written a better web application.

Whenever I play with Rails, or for that matter any other web framework, I get stuck on trying to find a problem to solve (or a set of requirements). Fortunately the Agile Development with Rails book from the Pragmatic Programmers has a nice little bookstore application that I can develop iteratively. I’ve put my latest adaptation of their depot application to use post-redirect-get (even works with ActiveResource scaffolds), UUIDs as ActiveRecord primary keys, HAML, SASS and RSpec on GitHub. Feedback is always welcome.

Not to long ago I posted an article on my favorite environment for software development. There was also a survey in that post asking about your favorite environment. The results are below.

Clearly, Linux is a winner. Here are some comments you guys added to a survey.

Can’t believe people are still using text editors to code… Visual studio rocks!

Well, not sure about this comment

Well, Ubuntu. For the package system, for the standard package archives and for the PPAs. And for everything else about it being good enough.

Windows 7, mainly because ive been using windows for, well ever. I find it really intuitive and i just know the tools really well. Windows 7 is really nice too.

Obviously I long for the day that will never come when I can develop my .net applications in intellij, deploy to a cut down windows vm for compilation and testing against iis… Anyway dreaming aside I pick mac osx for reasons you said and also because I have one and nothing beats dev on a native machine…

Mac is quite reasonable. Windows just feels clunky.

I need to be able to navigate to files and find things quickly, let alone use apps. Windows explorer/cmd is crap. Linux and Mac OS both work quickly and the command-line is effective. Mac OS X, however, just requires less of my time to maintain it than Linux. All three work similar from within an app like Eclipse.

Could be interpreted as a fan oy phrase, but for dev there is no better option than Linux…

I prefer Max because when I develop I am not just programming. Sometimes I need to check some screencast and last time that I used Linux (last year) I was not able to check all of them. Also I need a good mail and contact manager, I tried Thunderbird and Evolution. But none of them where satisfying my need.
Also i use my computer to develop and for personal use (creating video, music viewing videos). Linux is poor on that side.

I still have to fall back to Windows when working with clients who insist on using Outlook for calendaring and those horrible built-in surveys. Some aspects of my MacBook are pleasant, but I detest the keyboard layout – no home/end/pgup/pgdown and, worst of all, no visible # key

We all got a favorite environment, but what is the actual one that you use every day at work? I’m using Visual Studio as there is no real aternative to .NET development. Fortunatelly ReSharper makes it usable

Thanks for your answers guys, Greg

We finished last post with this funny situation: the abstraction that represents Facebook depends on our Domain Model.

It was a bit obvious that what we needed was not only system abstractions for Facebook, Twitter and the like but Bounded Contexts. We need to acknowledge the fact that these domains are not part of our model, even though we depend on them. We need to make this explicit.

The Facebook API doesn’t have the same concept of User as we do, and neither does Twitter. Someone has to translate from Profiles to Users. We identified the UserRepository as the best candidate for that.

The hugest advantage of this is proper dependency management. If you remember our last post, we had a circular dependency between system abstractions and our model. It was something like this:

But, by isolating message parsing from the user creation, we remove that red line. Facebook doesn’t create Users anymore, therefore it doesn’t depend on AllSocialNetworks/UserRepository. Will fall in a situation closer to this:

Now UserRepository will have access to everything it needs to create valid instances of User –and all it needs are objects returned by the system abstractions. The circular dependency problem is solved.

While moving this translation away from the system abstractions we learned that our situation was much worse than we first thought. The challenge looked simple, transform this:

Into this:

But indirect coupling among those classes was so strong that even with multiple levels of tests the effort to migrate all system abstractions to this structure is still in progress.

The Repository class is currently in a weird situation. It was already a very good candidate to be renamed to something else or, even better, split in two or more. After all those changes, though, that class is just too far away from whatever a Repository should be. This will probably be the next major refactoring that we have to do in this system.

But that’s another story, that maybe will be told another day…

Conclusion

In this example we went from this:

To this:

We sent from seven to thirteen classes. From two to four major packages/modules. Did this really help or we just went nuts on abstraction explosion?

All metrics I have gathered up to this point are positive. I am not talking about abstract metrics like cyclomatic complexity, efferent coupling and etc. –those are useful but won’t tell much without context. What tells me if those changes helped or not is how they impact the behaviour of the development team.

We went from a couple of fat and overdependent classes to many small classes with limited responsibility. This design is not suitable for all scenarios but it is what works well with most Object-Oriented models. If you consider that we are always adding more integration points -it’s an integration project after all- the extra flexibility and explicit concepts are really welcome to the system.

People in the team are more comfortable with the new model, it is easier to talk to the business and understand what they want done. It is also easier for newcomers to understand what the system is about and how to change it –how to map the vocabulary used in story narratives to classes and objects.

Looking at Subversion logs, we can see that commits tend to be contained into a given module. That means fewer conflicts to resolve and less contention –i.e. no or few God classes. In the end of the day this means that developers waste less time waiting for someone else to finish working with a given class and in rework.

On the bad side, making this refactoring while still delivering user stories is messy. It is really important to remember people frequently that we should not patch the old classes, but take the chance to advance towards the new model.

Unfortunately we were not pro-active enough to start refactoring and cleaning the code before having issues with circular dependencies and while playing a story one usually feels much more pressure to just fix the symptom than to solve the root cause.

Read the first post here.

In the previous post we were facing the problem demonstrated by the diagram below.

Our FacebookMessageParser needs an instance of AllSocialNetworks so that it can create valid Users coming from Facebook. The only implementation we have for the AllSocialNetworks interface is UserRepository, and this implementation needs a FacebookMessageParser. That’s a circular dependency, it becomes impossible to instantiate the objects above without breaking invariants.

The invariant of an object must be always fulfilled; once the invariant is broken the object is not valid anymore and your system is in an abnormal situation –i.e. I would expect it to throw exceptions like crazy and/or eventually die in pain.

The problem seems to be that we don’t have a single place that knows all the required information to create a User. In our system we have a situation where all Users have Facebook accounts, but some of them have Twitter accounts as well. For those with both types of account we must construct the user object with information coming from all Social Networks.

The first thing we thought about was that our problem was in how the User object was being constructed. One-step instantiation wasn’t working. Turns out that this is a common problem in Object-Orientation, so common that there is an old pattern that deals with it: the Builder design pattern. One of the consequences of this pattern is:

It gives you finer control over the construction process. Unlike creational patterns that construct products in one shot, the Builder pattern constructs the product step by step under the director’s control. Only when the product is finished does the director retrieve it from the builder. Hence the Builder interface reflects the process of constructing the product more than other creational patterns. This gives you finer control over the construction process and consequently the internal structure of the resulting product.

That sounds like exactly what we need here. So we draft a UserBuilder.

This object can be passed to the multiple parsers so that each one of those can populate it with the bit of information that it provides. In the end we call the createUser() method and receive a valid object back.

The next problem: who instantiates the Builder? The UserRepository is supposed to manage the lifecycle for the User, therefore looks like the perfect candidate. What happens, though, when we have a list of users instead of a single one? It sounds that this would be as simple as an operation that maps from one list of Builders to one list of Users:

But the Repository doesn’t know how many Builders should be created -the objects are complex enough so that a UserListBuilder is not an option. Sometimes the FacebookMessageParser is the one who knows how many Users should be created, in other situation the list is known only by the TwitterUserParser.

At that stage our team designed a very complicated strategy that would let the Builders be created in multiple different points depending on the situation. When you get to such complicated solution is possible that you are be missing the point entirely.

We started to realise that our problems may be being made worse given the heavy coupling between parsers, gateways and the Repository. In this post we are looking at only one pair of parser + gateway and it may look like it’s not a big deal, but in the system we had more than ten of those pairs.

The Repositories definitely know a lot more about the internals of each system than they should. Why would it care if Twitter data comes from messages we parse or from objects that we have, say, in cache? It shouldn’t!

The biggest problem that all this coupling was causing in our development process was in our Ubiquitous Language. The business people talked used to say something like “then we get the user profile from Twitter”, but in our heads we had to do the mental mapping –and mental mapping is bad- between the business lingo and what actually happened inside our model. To reduce the noise we created then objects that represent the systems we talk to.

These Facebook and Twitter objects –we called them system abstractions- were modelled after what we, as a business, need from those systems. The technical details about the need to establish a connection and then parse a message were encapsulated by those. We did increase the number of classes, but we reduced the size and complexity of them all.

One of the good things that this refactoring provided was that we could see some interesting patterns in our model that were previously hidden in the messy relationships. Take a look at a subset of the Facebook interface, for example:

The class that represents Facebook knows about our Users. It receives them as parameters and instantiates that class. Why the hell would Mark Zuckerberg care about our system? What that means, in a practical sense, is that changes that affect only our user have the potential to change our Facebook abstraction. The class changes if the Facebook API changes or if User changes. Having more than one reason to change is a smell, as Uncle Bob says:

Why was it important to separate these two responsibilities into separate classes? The reason is that each responsibility is an axis of change. When the requirements change, that change will be manifest through a change in responsibility among the classes. If a class assumes more than one responsibility, that class will have more than one reason to change.

If a class has more than one responsibility, the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’s ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

And that was true. A quick look through SVN history shows that every time there was a change in User we had to change at least one system abstraction -and we have many of those types of classes. In most cases those abstractions that were changed together with User had no real relation with the change being made.

It became clear that each of our third-party systems were actually Bounded Contexts. In Domain-Driven Design, Bounded Contexts are boundaries that we create around a model to isolate it from other models. We not only define what goes in and what stays out of a model, but we also define how different models relate.

We had already defined that those Bounded Contexts could only be accessed through their system abstraction. What we had to do was to remove the dependency from the third-party Bounded Contexts to our Domain Model.

We are going to see how we approached that in the next post.

• Not all classes are about interactions, sometimes they are about results.  Mocking everything out for the sake of it doesn't gain you anything.  Use state based testing to assert the end results not interaction testing to assert what is happening to achieve those results.  
• It's OK for your collaborators to new up something if you ask them, so you can say fileSystem.NewFile(name) if you need to.  
• Collaborators don't always have to be passed in the constructor: they can be passed as arguments to methods as well, so you can say new File('myfile.txt', 'Some text').SaveTo(filesystem).  
• If a class is unavoidably all boilerplate and co-ordination consider using integration tests, after all mocking the interactions of boilerplate code doesn't tell you anything useful at all.  
• The container shouldn't contain everything, it should be the things that generally require configuration or are likely to change: databases, filesystems, web services etc. Rarely do core domain classes or business principles need to be 'switchable'.

Mark Wilden pointed me to a post he's written about his experience pair programming at Pivotal Labs where he makes some interesting although not uncommon observations.

When you pair program, you're effectively joined at the hip with your pair. You can't pair if only one of you is there.

I've previously written wondering what we should do if our pair isn't around where I was leaning more towards the opinion that we should try to continue along the same path that we were on when working with our pair if they're gone for a short amount of time and to find a new pair or work alone if they're gone for longer.

On the projects I've worked on we'll still have times working alone when there's an odd number of people around or if someone just feels like working on their own and I think that's fine as well. I don't think we need to pair 100% of the time.

You have to be able to think out loud – 8 hours a day. Then you have to type in code while someone is watching you. They'll catch your typos (hopefully after giving you a chance to spot them yourself) and they'll see when you're floundering for how to do something.

I find that this is quite a useful practice for explaining things to yourself although I can see how it would initially exhausting.

Even now there are times when I just want to write some code instead of having to explain what I want to do to someone else. Sadly almost every time I explain something it turns out that my pair has a better idea of how to do it than me so I'm always glad pairing encourages this conversation.

Pair programming doesn't encourage quiet reflection and exploration. You can't just sit back and read some code. You can't just sit and think. I mean, you can, but then your pair is just sitting there.

This is a bit of a double edged sword – pair programming does encourage us to get things done but it's also true that sometimes we need to get the whiteboard out.

Often just sketching out the problem on a piece of paper to check your understanding is enough to trigger a conversation which might result in a better solution.

It does tend to need one person to drive this process though. I haven't seen it just happen organically.

We rarely pair 100% of the time so there are often times when you get a bit of time to play around a bit with the code and see whether specific approaches would work out and I often use this time for reflection and exploration.

One thing which a couple of the commenters on the original blog suggested is that perhaps more rotation was needed to help overcome some of the problems and from my experience it's vital that we do rotate otherwise the pair will end up hating each other!

I recently worked on a story with 3 other people across its life and each person pointed out something that I hadn't previously considered and which led to an eventual output that was much better than it would have been otherwise.

I think rotating different people onto a story can help lead to more innovative design as long as we have people working together who are relatively flexible and open to trying out new ideas.

Mark's post is certainly interesting though and helps identify some of the things we need to be aware of when pair programming – we don't just want to follow the practice blindly.

You should favor readability

Damn straight.

Favoring line count

I had sacrificed clarity at the altar of line count. And I was ashamed.

A (very brief) twitter discussion

What if no one reads it?

Fork the DocOnDev project

Clone your project

$ git clone git@github.com:[your-github-account]/functional-koans.git

Get the source

$ cd functional-koans
$ git checkout -b python
$ git pull origin python
From git@github.com:[your-github-account]/functional-koans
 * branch            python    -> FETCH_HEAD
Auto-merging README.markdown
CONFLICT (add/add): Merge conflict in README.markdown
Automatic merge failed; fix conflicts and then commit the result.

# Functional Koans


### About the Koans

There are several functional languages that have contributed their own
versions of the koans.  Each language has it's own branch with
detailed instructions on how to get started.

### Getting Started

To get the koans for a particular language, simply clone the repo and
checkout the branch:

'git clone git://github.com/relevance/functional-koans.git' 
'git checkout branch -b [branch_name]'
'git pull origin [branch_name]'


where [branch_name] is the name of the branch (language) you want to
work on.  To get a list of all branches run:

'git branch -a'

$ git add README.markdown
$ git commit -m'Fixed README conflict'

Add a remote to the original project

$ git checkout master

$ git branch -a
* master
  python
  origin/FSharp
  origin/HEAD
  origin/clojure
  origin/master
  origin/scala

$ git remote add DocOnDev git://github.com/DocOnDev/functional-koans.git

Just to be sure...

$ git fetch DocOnDev
From git://github.com/DocOnDev/functional-koans
 * [new branch]      FSharp     -> DocOnDev/FSharp
 * [new branch]      clojure    -> DocOnDev/clojure
 * [new branch]      master     -> DocOnDev/master
 * [new branch]      python     -> DocOnDev/python
 * [new branch]      scala      -> DocOnDev/scala

$ git branch -a
* master
  python
  origin/FSharp
  origin/HEAD
  origin/clojure
  origin/master
  origin/python
  origin/scala
  DocOnDev/FSharp
  DocOnDev/clojure
  DocOnDev/master
  DocOnDev/python
  DocOnDev/scala

Make your changes

$ git checkout python
$ git fetch DocOnDev python
From git://github.com/DocOnDev/functional-koans
 * branch            python     -> FETCH_HEAD

Request a Pull

Buzz是个好东西。一边玩Buzz，一边抓紧时间看了几本书。

Organizational Patterns 操作性缺缺，看完仍然不知道该怎么实施──甚至不知道能不能实施

说话的魅力 废话超过文化

演说之禅 “胶片”这个词真的很不好，因为它杂糅了幻灯片和讲义

让你的声音更有魅力 系统性和可操作性都太差了，国人写书的通病

还在读 Fearless Change 。原来Linda Rising就是模式年鉴的作者，难怪我听着那么耳熟呢。

Evangelist => Test the Waters => Time for Reflection => Small Successes => Step by Step

Ask for Help, Connector, Guru on Your Side, Innovator, and Just Say Thanks

You’ve had a meeting using the pattern Piggyback or Brown Bag. Perhaps you were able to Do Food and you scheduled the meeting at The Right Time. You brought some interesting books or articles, hoping to Plant the Seeds and point to External Validation for your new idea. You talked about the Next Steps for your fledgling effort and maybe you used e-Forum to help Stay in Touch with people who are getting interested in your work. If you were really lucky, your collection of like-minded folks has started to form a Group Identity.

昨天收到 Strength Finder 2.0 。

You might be especially adept at legal work, crafting sound business deals, or ensuring compliance to regulations.

郭晓说：I am surprised by Harmony!

伤了。

I recently came across 37 Signals 'Getting Real' book where they go through their approach to building web applications and there have certainly been some good reminders and ideas on the best way to do this.

These are some of my favourite parts:

• Ship it!
  

  If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that. The faster you get the user feedback the better.

  Often on projects I've worked on we've taken the approach that bugs get worked on before new stories which makes sense in a way because it means that we are fixing problems quickly and keeping the quality of the application high.

  In reality what often happens is that low priority bugs just end up not getting looked at but I like the fact that we can choose to make that an explicit approach rather than just allowing it to happen to us.

  Prioritize your bugs (and even ignore some of them)

  Just because you discover a bug in your product, doesn’t mean it’s time to panic. All software has bugs – it’s just a fact of life.

  I find it interesting that there might be more value in getting something out the door and then getting feedback on it rather than spending extra time perfecting it up front.

• Fix Time and Budget, Flex Scope
  

  You have to figure out what’s really important. What’s going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.

  From my experience a lot of times we end up implementing features just because that's what was agreed in the initial release plan and there is often a reluctance to change that even if a feature isn't really that useful anymore.

  It becomes even more problematic if we get to the stage where it's not possible to deliver all the features promised in the remaining time so it certainly makes sense to me that in that situation we would look to focus on getting the absolutely essential things in first.

• Choose any enemy
  

  Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.

  This seems to be a much better idea than just copying the ideas of your competitor which might seem the obvious thing to do if you're working in the same area.

  The problem with that approach of course is that when you do copy you have no actual vision of what you're doing with your application anyway so you'll always be playing catch up.

• Don't overcomplicate the application

  There are a few parts of the book where the authors talk about keeping the application simple and then letting the users play with it:

  The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.

  Keep it small. Keep it simple. Let it happen.

  Andrew Hunt, The Pragmatic Programmers

  The users can then decide for us where we need to fill in more details:

  Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.

  In particular they suggest that focusing on very specific details about the page layout/colour/wording can be left until later because it will only serve to hinder forward progress if we concentrate on it too early.

• Scaling an application
  

  You don’t have a scaling problem yet

  “Will my app scale when millions of people start using it?”

  Ya know what? Wait until that actually happens.

  On several projects that I've worked on there often seems to be a desire to focus on performance and scaling an application very early on which seems wasteful when we could be focusing on actually building something that has so many users that we need to scale it later on. I think this advice is spot on.

• Write less software

  A common theme throughout the book is that of writing less software to achieve our goals:

  The best designers and the best programmers…are the ones that can determine what just doesn’t matter.

  That’s where the real gains are made.

  Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

  Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.

  Throw away customer feature requests – if they're really important then they'll come back anyway

  Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.

  The authors ideas around preferences were particularly interesting to me:

  Preferences are also evil because they create more software.

  More options require more code. And there’s all the extra testing and designing you need to do too.

  I hadn't appreciated until recently quite how much complexity we can add to an application by allowing users to play around with the display of information on a screen.

  It seems like a nice feature to have but it would be interesting to see statistics that could tell us what percentage of users actually that type of thing when it's not the core idea of the application.

  I also quite liked the following and I think it's something that we need to do more often on teams:

  Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.

• Decisions are temporary so make the call and move on
  

  So don’t do the “paralysis through analysis” thing. That only slows progress and saps morale.

  Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.

  I think a big part of this is getting the mentality that it's fine to make changes after we've 'finished' something. Any other approach doesn't work from my experience.

• Reduce meetings
  

  Meetings usually arise when a concept isn’t clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire.

  I find it interesting that they prefer communicating by email because I've often found that it's not the best communication mechanism since it's really easy to misinterpret what people mean.

  Having said that if we can make concepts clearer and the need for a meeting is an indicator that we need to do that then perhaps we can still meet in person and just make the meeting much shorter.

• Design the interface before you start programming
  

  Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.

  I've certainly fallen into this trap a lot but I've been trying to follow the outside in approach more strictly recently and so far I'm finding that it reduces the feedback cycle quite substantially which is only a good thing.

• Design for regular, blank, and error states
  

  For each screen, you need to consider three possible states:

  Regular
  The screen people see when everything’s working fine and your app is flush with data.

  Blank
  The screen people see when using the app for the first time, before data is entered.

  Error
  The screen people see when something goes wrong.

  I'd never even though of this at all and I'm certainly guilty of only ever considering applications when all the data is filled in so this is certainly something else to consider.

• Tear down the walls between support and development
  

  In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

  My colleague Chris Read and some others seem to be trying to close this gap with the devops movement which also has a track at QCon London this week.

  The idea of working in support to see what an application is like from that perspective is something that more experienced colleagues often recommend although I've not done it as yet.

Overall I found this book a really interesting and quick read and although many of the ideas suggested seem like common sense it's strange that we often don't do all of them.

The 37 Signals guys also have a new book coming out in the UK tomorrow titled 'Rework' which sounds like it could be quite a good read as well.

When I discussed VersionControlTools I said that it was an unscientific agglomeration of opinion. As I was doing it I realized that I could add some spurious but mesmerizing numbers to my analysis by doing a survey. Google's spreadsheet makes the mechanics of conducting a survey really simple, so I couldn't resist.

I conducted the survey from February 23 2010 until March 3 2010 on the ThoughtWorks software development mailing list. I got 99 replies. In the survey I asked everyone to rate a number of version control tools using the following options:

• Best in Class: Either the best VCS or equal best
• OK: Not the best, but you're OK with it.
• Problematic: You would argue that the team really ought to be using something else
• Dangerous: This tool is really bad and ThoughtWorks should press hard to have it changed
• No opinion: You haven't used it

The results were this:

As well as the raw summary values, I've added two calculated columns here to help summarize the results.

• Active Responses: The total of responses excluding "No Opinion". (eg for git: 65 + 19 + 1 + 0)
• Approval %: The sum of best and ok responses divided by active responses, expressed as a percentage. (eg for git: (65 + 19) / 85)

The graph shows a scatter plot of approval percentage and active responses. As you can see there's a clear cluster around Subversion, git, and Mercurial with high approval and a large amount of responses. It's also clear that there's a big divide in approval between those three, together with Bazaar and Perforce, versus the rest.

Although the graph captures the headline information well, there's a couple of other subtleties I should mention.

• Although the trio of Subversion, git, and Mercurial cluster close together on approval, git does get a notably higher amount of best scores: (65 versus 20 and 33).
• VSS got the most "dangerous" responses, but a couple of people approved of it.
• Neither TFS or ClearCase are liked much, but ClearCase got more "dangerous" responses than TFS (41 versus 22).
• Don't read too much into small differences as I'm sure they aren't significant. I'm sure the difference in approval percentage between VSS, TFS, and ClearCase isn't signifcant, but the difference between these three and the leaders is.

Some caveats. This is a survey of opinion of ThoughtWorkers who follow our internal software development discussion list, nothing more. It's possible some of them may have been biased by my previous article (although unlikely, since I've never managed to get my ThoughtBot opinion-control software to work reliably). Opinions of tools are often colored by processes that are more about the organization than the tool itself. But despite these, I think it's an interesting data point.

I should also stress the important point to take away from this isn't the comparison between those close in the numbers, eg comparing git and Mercurial or comparing TFS and ClearCase. Any survey like this has a certain amount of noise in it, and I suspect the noise here is greater than such a difference. The important point is the big approval gap between the leading tools (Subversion, git, and Mercurial) and the laggards - essentially the point in VersionControlTools.

I’ve written in the past about the government’s abysmal track record on IT development.  I met with the local MP to discuss the issues but he didn’t really get it; he sent me away to write a policy paper for him which I really had time for…  So good news that someone is doing something about it with a petition on the Number 10 website.

In his recent update on the progress of the petition, Rob Bowley mentions the Rural Payments Agency project.  I can’t attest to either have been an ‘expert’ or to have had a salary anything near what he mentions, but I was a consultant on that project so nod in informed agreement.  That experience gave me a benchmark to compare ‘bad’ ways of going about an IT project to compare with the ‘good’ world of lean and agile that I now inhabit.

Please sign the petition.

agile |ˈajəl|
adjective
able to move quickly and easily : Ruth was as agile as a monkey | 
figurative his vague manner concealed an agile mind.

It's not that you can't communicate

You just need to communicate differently

The future is so bright, I should wear shades!

© Sumeet Moghe, 2009

1. Lesser rework during development on account of misunderstood/ill-defined requirements. These things surface quickly when pairs talk to each other.
2. Slight reduction in maintenance cost on account of clearer code. Because every line is now considered readable by at least two people. (more in case of pair rotation)
3. A better detail level design results when each pair acts as a sounding board for the other. Good design reduces cost of future change.
4. Faster/better process of bringing new team members up to speed.
5. Lesser impact of people taking vacations.
6. Lesser bugs in QA, UAT
7. More hours of focused work per day - however professional someone may be it is natural for concentration to wax and wane. Pairing almost always helps here. 
8. Unlike the case of no-pairing, there is no separate code-review activity required
   

blog home page

I've been working in ActionScript lately. It's a bizarre language. Java-style OO features are smashed right on top of JavaScript, with no regard for the prototype-based inheritance that the language has had all along. (As far as I can tell Adobe doesn't want you to think about prototypes. I haven't dug into how the Java-style ActionScript class model plays with the prototype model, but it might be worth exploring.)

After a few years of full-time Ruby, the adjustment has been pretty painful. One of my biggest complaints is the verbosity of the static type declarations. Having recently spent some time playing around with Scala, I was incredibly impressed at how much noise can be removed from a statically typed language with a compiler that does good type-inference. The ActionScript compiler does absolutely zero type-inference, and the result makes for really nasty reading.

One of the additions to JavaScript syntax that initially impressed me was the introduction of the const keyword. I really appreciate how Scala's val keyword makes declaration of immutable fields just as terse and clear as the var keyword does for mutable fields. This is in contrast to Java, where making things immutable requires an extra keyword (final) that makes code with immutables (i.e., better, safer code) extra noisy, a great disincentive to doing the right thing. Using const in place of var in ActionScript is much prettier than the Java way. Unfortunately I quickly discovered a couple of shortcomings in ActionScript "constants" that really bummed me out.

The first issue I ran into very quickly: Whereas Java only allows final variables to be assigned once, it's smart enough to allow that assignment to happen in a constructor. The ActionScript compiler specifically requires them to be assigned at the point of declaration. This means you can't declare a constant field and assign it its value in a constructor, which is the primary reason I'd want constant fields.

Boo! But const was still good for static constants (obviously) and seemed to be good for locals as well.

The second issue has to do with using const on locals and led to a pretty painful debugging session. We were taking advantage of one feature ActionScript holds high over Java's head: functions are closures, and closures are handy. I was looping over some data structure using a for loop. Inside that loop I declared a const, then declared a function I wanted for later that used that const. But at the end of the loop all the functions were referring to the last item in the data structure.

Here's some sample code illustrating what I was seeing.

// Maps an array to an array of functions that return
// the values from the original array.
// But doesn't work!
function identityFunctions(items:Array):Array {
  const functions:Array = new Array();
  for (var i:int = 0; i < items.length; i++) {
    const item:* = items[i];
    functions[i] = function():* { return item; };
  }
}

const funcs:Array = identityFunctions(["a", "b", "c"]);
funcs[2](); // => "c", as desired
funcs[1](); // => "c", but I wanted "b"
funcs[0](); // => "c", but I wanted "a"

Here's something I either never knew or at some point forgot about JavaScript: variables are lexically scoped, but only function bodies introduce new lexical scopes. So even though that item const is declared inside the loop, it's really scoped to the entire function. It gets assigned a new value on each pass of the loop, so yes, the const keyword is a bold-faced lie. Apparently the keyword tells the compiler not to let any other code assign to that reference, but it creates a mutable reference just like var, and in this case it gets repointed several times.

Basically the function definition above compiles into the same thing as this.

// Comes right out and tells you it doesn't work.
function identityFunctions(items:Array):Array {
  const functions:Array = new Array();
  var item:*;
  for (var i:int = 0; i < items.length; i++) {
    item = items[i];
    functions[i] = function():* { return item; };
  }
}

Certainly it's my bad not knowing that the for loop doesn't introduce a lexical scope, but it's crazy for the compiler to allow declaration of a const inside a looping structure. If Adobe's really committed to all this static typing and compiler checking hooey, surely they'd agree this is a nasty gotcha that the compiler should prevent.

As far as workarounds, there are several. For the contrived example above, the simplest is to use one of the iteration methods Array has in ActionScript. There the "body" of the loop is a function, so it has its own scope. Here's the cleanest way.

// Actually works.
function identityFunctions(items:Array):Array {
  return items.map(function(item:*, i:int, a:Array):* {
    return function():* { return item; };
  });
}