Mark Needham

Thoughts on Software Development

Archive for the ‘Lean’ Category

Shu Ha Ri harmful?

without comments

I came across a blog post by Rachel Davies where she wonders whether the Shu-Ha-Ri approach to learning/teaching is actually harmful and I found Rachel’s thoughts around the teaching of principles and practices quite interesting.

Quoting Jeff Sutherland:

Only when you have mastered the basic practices are you allowed to improvise. And the last and most important – Before you have gained discipline, centering, and flexibility, you are a hazard to yourself and others.”

I’m uncomfortable with approaches that force students to follow agile practices without questioning. These approaches seem to violate the first value of the Agile Manifesto “Individuals and interactions over processes and tools.”

What I find interesting about this is that when I first started learning about agile I would read the principles and they would all make sense but I didn’t know what to do with that knowledge.

It was only after I’d used the practices frequently and in most cases taking the practices too far that I reached the stage where I could start asking questions that actually had any relevance.

For example Test Driven Development is one practice that I learnt and one of the principles which encourages this approach to coding is the need to get quick feedback on our work.

It would be quite easy to question whether we should test drive everything and you could quite correctly have the opinion that we shouldn’t use this approach for absolutely everything.

However, without spending some time following this practice that opinion wouldn’t be particularly useful because you would lack the experience that tells you which type of code we should or should not look to test first.

Having decided that TDD was the only approach to writing code I eventually got into situations where it didn’t seem to make sense to stick so rigidly to this practice and it was only then that the value of the underlying principle became clear to me.

I don’t think I was ever forced not to ask questions but I was just so concentrated on learning how to do the practices properly that I focused on that.

I often find that it’s useful to use practices too much until you cause yourself pain.

Martin Fowler has a nice graph which shows how people adopt meta programming when coding Ruby and I think this links quite closely to my experiences when learning a new practice.

For me at least this seems to be a necessary learning step before I eventually step back and think about the principle that originally led me to following that practice. I can then start using the practice again but in a more effective or intelligent way.

What I’ve described above is often the way that I learn new things but I’m sure that others’ experiences will vary so it’d be interesting to hear about other approaches too!

Written by Mark Needham

February 26th, 2010 at 11:53 pm

Posted in Lean

Tagged with

Set Based Concurrent Engineering: A simple example

with 6 comments

One of my favourite ideas that I came across while reading the Poppendieck’s Lean Software Development is set based concurrent engineering which encourages us to keep our options open with regards to the solution to a problem until we absolutely need to decide on an approach after which we probably can’t easily change that decision so we will most likely stick with it.

I like the idea but on the projects I’ve worked on we often seem to take a more point based approach – there will be some discussion up front on the potential solutions to a problem and eventually one of them will be considered to be the best solution and we go and implement that one.

Last week we were doing more work on getting an authenticated user into our system and on this occasion we were trying to work out the best way to get some of the user’s details into our ‘Service’ base class so that we could send down the user’s SAML token with specific requests.

We identified two solutions to do this – inject the user into the Service through a constructor or inject it via a property.

A colleague and I were in favour of the constructor based approach since it results in us creating an object which has all its dependencies ready at creation.

Erik and another colleague favoured the introduction of setter injection in this case since we could just add that to the top level abstract class and avoid the problem that we would have with constructor injection whereby every sub class would need to have that constructor defined.

public abstract class Service
	public Service(User user)
public class SomeService : Service
	public SomeService(User user) : base(user) { }
	// every sub class of Service would need this constructor

We decided to try out both of these solutions concurrently for a time boxed period and then go with the one which looked like it was working out better.

While pursuing the constructor based approach we actually ran into a problem trying to resolve the services – it seems to be a bug in Unity Container version 1.2 which doesn’t allow you to use parameters in the constructor of a type which is being intercepted by a ‘VirtualMethodInterceptor’ which we are making use of for caching some service requests.

We spent a bit of time trying to debug this to work out what was going on but the code eventually fails when trying to emit some IL code.

I tried the latest version of the container out separately and it seemed to work correctly for the same situation so I think the bug has been fixed now.

By this time the time box was up and my other colleague had got further with the setter based approach than we had managed to get so we decided to go with that approach instead.

I think it was still an interesting approach to take as we learnt a bit more about how the container works and we got to see the trade off that we would be making if we used constructor injection between keeping our objects ‘pure’ and creating a lot of boiler plate code to create the constructor for each new service class – we went through about 30 classes putting the new constructor in!

Written by Mark Needham

September 19th, 2009 at 2:24 am

Lean: Big Picture over Local Optimisations

with 7 comments

I recently finished reading Lean Thinking and one of the things that was repeatedly emphasised is the need to look at the process as a whole rather than trying to optimise each part individually.

If we phrased this in a similar way to the Agile Manifesto it would probably read ‘Big Picture over Local Optimisations‘.

The examples in Lean Thinking tend to be more manufacturing focused but I think this idea can certainly be applied in thinking about software projects too.

Individual vs Team Focus

For me on a software development team what we care about is the quality of the team as a whole not the individuals on it.

It’s all good being very strong technically but you have to be able to work effectively with other people to solve problems otherwise your value to a development team is much reduced.

I wrote a bit about this previously in my lean look at pair programming but I think it goes beyond just ensuring that we are sharing knowledge around the team by having people collaborating closely with each other.

When I first joined ThoughtWorks my former colleague Fred George was always talking about the value of being poly skilled – having the ability to carry out more than one role – and I think this is lost when we refer to people as being their role i.e. ‘you ARE a developer’ rather than ‘you CAN PLAY the developer role’.

If we have people on a team who are polyskilled or generalising specialist (although I think generalising specialist refers more to poly skilled across a role rather than being able to carry out multiple roles) then we can get away with building teams which are smaller in number and which are more resilient and able to respond when team members are ill or absent.

Horizonal vs Vertical teams

Creating teams of people by the layer or horizontal which they work on rather than the piece of functionality or vertical which they are working on seems to be one of the most obvious ways of locally optimising instead of looking at the big picture i.e. the delivery of a piece of functionality to the business.

I guess the theory is that if we put everyone working on similar things on the same layer in the same team then it will result in greater productivity than having people who are working on different areas of the system but have the same underlying goals.

The problem is that we create a lot of handover points – opportunities for context and information to be lost – and the ineffectiveness of this approach as a communication mechanism means that it takes much longer to integrate the components from each horizontal than it would have done with a team with people from each layer in it.

In addition any techniques used to try and increase the productivity of an individual team will be ineffective since they will only satisfy a local optima and will have a knock on effect to the rest of the system.

For example, let’s say we have three teams A, B and C and team B aren’t as productive as we were expecting. Applying pressure to team B may have an impact on their immediate productivity but it’s likely to affect the other two teams since team B will probably be less communicative towards those teams since they are trying to optimise their own performance.

Having a vertical team which is responsible for the delivery of a feature or features end to end works much better from my experience.

Colocated vs Distributed teams

One of my favourite agile ideas is having a co-located team, with the business people, analysts and developers all working in the same physical location.

Sometimes though the decision is taken to distribute teams across multiple locations – be it because that’s more convenient or cheaper to do.

The big picture i.e. project delivery is likely to become more difficult to achieve due to the increased cost of communication that has been created.

For me there is nothing better than face to face communication – even with phone calls/instant messaging/emailing it is still an extremely valuable form of communication. With any of the other three it’s much more difficult to read what someone is really thinking and you can come across as being much more aggressive than you intended to in any of those mediums.

My colleagues in India/China will certainly have some tools/techniques to bridge these gaps that I’m not aware of but I still remain convinced that if we have the choice then a co-located team is the best choice.

In Summary

These are just some of the ideas that came to mind when trying to apply one of the principles of lean to software development teams. Although many of these may seem obvious sometimes it takes another angle of looking at the problem to make that visible.

If you can think of any others feel free to mention them in the comments.

Written by Mark Needham

April 14th, 2009 at 10:10 pm

Posted in Agile,Lean

Tagged with