Chris Sterling’s Blog

George Dinwiddie, a wonderful blogger on Agile software development, wrote on “Working Hard? Or Hardly Working?”. Please read his blog and then you can read my comment below:

Good day George,

I read your blog all the time and enjoy what you write about. This blog entry caught my attention and I had to respond.

The one problem I have with the judgment of “working hard or hardly working” is that is presumes that working hard is always good. A large issue in our industry is the “busy-ness” factor of all people involved in the organization from executives to managers to developers and operations. We all are too busy and therefore our hard work turns into adding more work than if we were to slow down and make better decisions about how to complete the work best.

So, even if someone could tell if another person is “working hard” or “hardly working” I am not sure this is a good measure of anything. In the end I would rather understand if the organization or product team as a whole is getting faster in their delivery of valuable software. If this is the case then all people involved are improving their capabilities for the good of the whole.

Coincidentally, Tom Perry wrote on “Measuring Productivity = Continuous Improvement?” where he makes many references to “monkeys” but also makes a conclusion that teams can create their own productivity metrics to help improve their own delivery capabilities rather than management defining problematic measurements for the team that create poor responses.

Both blog entries have great information and references in them and I hope that those of you interesting in “measuring productivity” take a look. I am still on the Alistair Cockburn side of the house when it comes to measuring productivity. I believe it cannot be done but that doesn’t mean that the team cannot create metrics that help them improve.

And finally I will just point you towards Ron Jeffries wonderful writing on “Productivity” from “Annals of Kate Oneal”.

Comments Off on The Illusions Created by “Working Hard”

In a Certified ScrumMaster course this week one of the teams created some haiku on the topic of user stories. Here is what they came up with:

INVEST your time in telling stories that give you meaning moving on…

Unique perspective inward and outward focused simply understood

The user wishes to do something on the site they do not know why

Start with a user a new or improved feature gives us the value

As a Scrum novice I want to learn this method so that we can plan

The confirmation makes conversation simple and settles details

Not bad for 5 minutes worth of work. Some of the items that were referenced:

• INVEST model
• User Story template
• 3 C’s of a User Story

1 Comment »

This is a bit off my usual topics on this blog but I am a heavy open source user and this article is something that I hope gets to more enterprise operations, managers and executives. I have been using and deploying production available applications using open source tools, libraries, and platforms for over 12 years now. Open source tools can do almost anything commercial products are able to do and have transformed the software industry in that time span. The list given in the article contains open source projects that I would recommend and have used in the past either directly or indirectly including *nix tools and libraries shown.

I would like to add to this listing with some of the tools I have come to use often:

• Maven 2.x+ (http://maven.apache.org/)
• JBoss (http://www.jboss.org/)
• Rio/Jini/Apache River (http://incubator.apache.org/river/RIVER/index.html)
• Apache Commons (http://commons.apache.org/)
• Subversion (http://subversion.tigris.org/)
• Apache Web Server (http://httpd.apache.org/)
• Bouncy Castle (http://www.bouncycastle.org/)
• Time and Money (http://timeandmoney.sourceforge.net/)
• Spring Framework (http://www.springframework.org/)
• Hadoop (http://hadoop.apache.org/)
• Ruby on Rails (http://www.rubyonrails.org/)

This is some of the open source that I have and still use on my projects. What are your favorites that were not on the list?

3 Comments »

For multiple years now I have thrown around the name “Executable Design” to describe Test-Driven Development (TDD) and how it is used for design rather than a test-centric tool. The name itself causes problems for those who are initially introduced to the technique. As a coach I was looking for a way to introduce it without stereotyping it as extra tests inhibiting more code getting delivered.

From my readings of multiple books, articles, and blog postings along with my own experiences with TDD the content of what I am about to distill is not new. This post is entirely about explaining the technique in a way that garners interest quickly. There are multiple pieces to “Executable Design” beyond the basic process of:

• Red, Green, Refactor or
• Write Test, Write Code, Refactor

These statements and the technique is the basis for practicing Executable Design but are not sufficient for describing the value and nuance of the practice. Not that I will be able to present it sufficiently in a single blog post but I want to present the basic principles.

While in a meeting with a team recently we were presented with a question I have heard often:

“Why should we use TDD?”

There are many reasons but generic reasoning alone is not sufficient. We discussed the safety net that good code coverage creates. We discussed the reason system tests do not take the place of unit tests. Then we started to touch on design and this is where it got interesting (and usually it does about this time for me). Before I can describe the rest of this discussion I want to present what lead up to this meeting.

A coach that I highly respect seemed a bit preoccupied one day when he wandered into my team’s area. I asked him what was going on and he told me that some of his issues with the current team he was coaching. He wondered why they were not consistently using TDD in their day-to-day development. The team had allowed a card saying “We do TDD” onto their Working Agreement and were not adhering to it.

I happened to know a bit about the background of this project that our company has been working on for over 2 1/2 years. There is a significant legacy codebase developed over many more years with poor design, multiple open source libraries included, and heavy logic built into relational database stored procedures. Also, just recently management on the client’s side had changed significantly and caused quite a shake up in terms of their participation and guidance of release deliverables. Yet the team was supposed to deliver on a date with certain features that were not well defined. This lead me to discuss the following situations that a coach can find their way into:

1. You could come into a team that has limited pressure on features and schedule and has considered the impact of learning a new technique such as Executable Design. Also, they have asked for a coach to help them implement Executable Design effectively. This is a highly successful situation for a coach to enter.
2. You could come into a team that has deadline pressures but has some leeway on features or vise versa and has considered the impact of learning a new technique such as Executable Design within their current release. Also, they have asked for a coach to help them implement Executable Design effectively. This is somewhat successful but pressures of the release rise and fall in this situation and may impact the effectiveness of the coaching.
3. You could come into a team that has deadline pressures and has not considered implementing Executable Design seriously as a team. Also, they have NOT asked for a coach and yet they have gotten one. The coach and the techniques they are attempting to help the team implement may seem like a distraction to the team’s real work of delivering a release. This is usually not successful and please let me know if you are a person who is somewhat successful in this situation because we could hire you.

The current team situation seemed to be more like #3 above and therefore the lack of success in helping the team adopt TDD did not surprise me. Also, I started to play devil’s advocate and provide a list of reasons for this team NOT to do TDD:

• At current velocity the team is just barely going to make their release date with the minimum feature set
• Not enough people on the team know how to do TDD well enough to continue it’s use without the coach
• The architecture of the system is poor since most logic is captured in Java Server Pages (JSP) and stored procedures
• The code base is large and contains only about 5-10% test coverage at this time
• It sometimes takes 10 times longer to do TDD than just add functionality desired by customer

This is not the full list but you get the picture. Don’t get me wrong, the list above begs to me the need for Executable Design but if the team does not have significant experience to implement it effectively it could seem overhead with little benefit to show for it.

After discussing this and more stuff that I won’t go into he told me about a couple of things that he can do to help the team. One of them was to work on minimizing the reasons for not doing Executable Design by discussing them with their ScrumMaster and actioning them on the impediments list. Some of those actions would go to upper management who get together each day and resolve impediments at an organizational level. One of the actions was to get our CTO and myself into a room with the team so they can ask the question “why should we do TDD?”.

Now we are in the room and most of the team members had been exposed to TDD through pairing sessions. Some of them had some ideas about where TDD was useful and why they thought it was not on this project. During the discussion one of the team members brought up a great discussion point:

“One of the problems with our use of TDD is that we are not using it for improving the design. If we just create unit tests to test the way the code is structured right now it will not do any good. In fact, it seems like we are wasting time putting in unit tests and system tests since they are not helping us implement new functionality faster.”

This team member had just said in the first sentence what I instinctually think when approaching a code base. The reason to do TDD is not just to create code coverage but to force design improvement as the code is being written. This is why I call TDD and its best known principles and practices of applying it Executable Design. If you are not improving the design of the application then you are not doing Executable Design. You might be just adding tests.

Some of the principles I have found to help me in applying Executable Design effectively are (and most, if not all, of these are not something I came up with):

• Don’t write implementation code for your application without a failing unit test
• Separate unit tests from system and persistence tests. (as described in this previous blog entry)
• Create interfaces with integration points in a need-driven way (as described in this previous blog entry)
• Always start implementing from the outside in (such as in Behavior-Driven Development and as described in this previous blog entry)
• Mercilessly refactor the code you are working on to an acceptable design (the limits of which are described in this previous blog entry)
• Execute your full “unit test” suite as often as possible (as described in this previous blog entry)
• Use the “campground rules” of working in the code: “Leave the site in better shape than when you arrived”
• Create a working agreement that the whole team is willing to adhere to, not just what the coach or a few think is the “right” agreements to have.

Try these out on your own or with your team and see how they work for you. Modify as necessary and always look for improvements. There are many thought leaders in the Agile community that have written down important principles that may work for you and your team.

And finally, now that I have filled an entire blog post with “Executable Design” what do people think about the name? It has worked for me in the past to explain the basic nature of TDD so I will use it either way unless others have better names that I can steal?

2 Comments »