Recommended Reading

I’ve been wanting to put together a recommended reading list for some time now, so I guess I’m going to not let “best” be the enemy of “better” and just do it.  I have added a small link to it below the “about me” side bar (which I will work on making more prominent soon… need to clean up the sidebars at some point).

Or you can use this link to view my recommended reading list.   None should be a terrible surprise if you’ve read any of my posts.  I’ll go back and elaborate on them more in the future (give my reasons and analysis) as well as expand (and possibly contract) the list.  Enjoy!

Good vs. Great; Better vs. Best

In Good to Great, Jim Collins states that “good is the enemy of great.”  In Working Effectively with Legacy Code, Michael Feathers states that “we can’t let ‘best’ be the enemy of ‘better’”.

On the surface these seem contradictory, but I would argue that they are, in fact, complementary.  I have been very much guilty at times of getting “analysis paralysis”, being overly concerned with the “right answer” or the “right way”.  In that case, where you have nothing, doing something is better than doing nothing.  At the very least, doing something, even if it’s wrong, gives you feedback that it’s wrong and you can move on.  The trick is to do something that is low risk.  The smaller your something is, the faster you can get feedback and adjust.

This goes with the “release early” philosophy of agile.  The other part of that philosophy is “and iterate” which is important as well.  Getting something done allows you to take it and improve it.  Having something concrete via quick prototyping or tracer bullets and iterating can get you there faster than waiting for the “right way” to become apparent.  If we always think “I don’t have time to make it perfect so I won’t do anything” we will never do anything.  “Best” becomes the enemy of “better.”  Martin Fowler said as much:

When you actually sit down to write some code, you learn things that you didn’t get from thinking about them in modeling terms. There is a feedback process there that you can only really get at from executing some things and seeing what works.

Once we get something good enough, the problem then becomes the attitude that “I don’t think it’s worth the effort to improve it, it’s good enough.”  And here is where “good is the enemy of great.”  The problem becomes when everything is humming along “well enough” that we become complacent.  That is until something shakes things up.  Like when the weight of defects reported become overwhelming because the code was not kept clean and non-legacy (no automated tests).  Or when an economic downturn hits and you realize that you didn’t take the opportunity during the “good years” to fine tune things or expand and improve and are now faced with tough decisions.

We need to be constantly improving (in code, in business and life), not settling for good, striving for great, but not so worried about best that we don’t pursue better.

Absentee Management

I heard the report “3 Weeks After Quake, Shelter A Main Concern in Haiti” on NPR recently.  It made me quite sad to hear about all the people that want to help (from inside and outside Haiti) and those that want to get started with rebuilding their lives, but are unable to do so with any sort of efficiency because of a lack of any sort of management direction (from the government of Haiti or the UN or anybody).

If you don’t have time to listen to the report (only about 4 minutes long), some of the phrases in there are:

• Some feel that they “should be focused on a longer term solution”
• Some reconstruction is taking place but “not under any sort of coordinated plan”
• Some are working on their own but it “can be quite dangerous”
• The government is “working toward a plan, discussions taking place”

“Discussions taking place”?  One of my favorite phrases lately has been “talk does not cook rice”.  In this case, talk does not save lives or rebuild a country.

So what does this have to do with software development?  In agile we often talk about “self-organizing teams”.  Often we talk about “getting out of the way of the team”.  This does not mean that management has no role in agile.  In fact I would argue that management’s role is even more important!  At the very least managers are responsible for:

• giving parameters for the work to be done (may be in the form of backlog, a product vision),
• providing necessary resources to the team (monetary or people) and
• removing the team’s impediments (make sure the team isn’t stuck).

This means that they should be doing, not talking.  Mapping out a course, not just discussing it.  Figuring out which way to point the team next and getting them the resources to get there.  Otherwise the teams will start taking things into their own hands and that “can be quite dangerous.”  At the very least it will result in wasted effort. 

Even in an extreme case like Red Gate’s “Down Tools” experiment (which I’m curious to see what the results are) you can see these elements:

• “The only aim is to create something relevant to Red Gate that you wouldn’t have created otherwise.” – but there is a clearly stated aim and “The only rule is that you have to complete something by Thursday lunchtime.”
• “Each team will have a discretionary budget of £500 for hardware / software / other stuff we don't already have in the building” – while this may not be enough for a super ambitious project, it should be more than enough for 4 days and it does set some parameters.  Most importantly it says “we’re behind this… with our pocketbook”

A team that is trying to self-organize without management’s direction and help is going to fail almost by definition as they won’t know what to look for in success.  Obviously the stakes for the people of Haiti is much higher, as in many cases we are talking about survival, not just another software project.  But just like the people of Haiti, if a development team has no direction, no resources and no help with impediments, the journey will continue to be bumpy.

Blame tied to Responsibility

When code with a major defect is released to the customer, who’s fault is it?  Who do we blame?  Scott Bellware just posted basically saying “it’s not the tester’s fault”.  I think it’s fair enough to say that the “QA missed something” syndrome is not healthy, but neither is “there's nothing that QA has ever missed that developers didn't miss first”.  The problem with the argument that “It's less of a tester's job to check that a developers' code is right, but that their tests are right” also implies that the tester didn’t “do their job” because they didn’t find the holes in the tests that lead to the defect not being caught and therefore, released.

This finger pointing usually happens in organizations where “QA” is the “gatekeeper”.  Sometimes that is the role that the organization has given them or the one that they have set up for themselves.  Either way they have implicitly set themselves up as being blamed for any defects that are released.  Is that fair?  Maybe not, but you can’t have it both ways.  You can’t simultaneously be responsible for it and not get the blame.

Of course this is coming from a programmer. So what’s my point?

The attitude on an agile team should be the team missed something.  And in an agile organization, “the whole organization missed something.”  To pin responsibility for any particular failure on any one particular individual or role in an agile team is to absolve the other members of the team from responsibility for success or failure of the team.  The attitude becomes, “if QA is responsible, I can’t get blamed.”  Or conversely “if the programmer is responsible, I (the tester) can’t be blamed.”  Take away the “safety net of blame” and attitudes change… but more on that in the future.

So when a defect is released, who failed?  The programmer failed, the analyst failed, the tester failed, the user during UAT failed.  In reality the whole team failed, agile or not.