Jerry Weinberg has a new book out Weinberg on Writing: The Fieldstone Method and it's got me blogging again.
If you would like to hone your writing skills then I recommend both this book and also On Writing by Stephen King. The latter is the first book I have ever read by King, as I am not a fan of horror or thrillers, and even this is a gripping read, as it mixes tips on writing with his life story.
Last year, I was lucky enough to attend a Writers Workshop run by Jerry Weinberg in Albuquerque, New Mexico. It did me a lot of good getting out of a hectic project into a peaceful environment, where I could do some writing and thinking. I realized that traveling to London everyday, to be a buffer in arguments about software architecture, was leaving me drained and it was probably time for me to move on.
Here are a few tips I picked up at the workshop:
* Buy a chair with good back support. At the time, I used to sit at my computer on an old blue bentwood chair that I pulled out of a skip 20 years ago, now I have a nice Aeron chair and no backache!
* Writing is a bit like extreme programming - it helps to separate out adding the activity of new features from refactoring. Now I don't make corrections as I write, I get the thoughts down in words first and then I go back to reorganize and edit.
* I used to do all of my writing on my laptop. I still do most of my writing on my laptop but I find that I can generate more ideas and connections between ideas if I switch from computer to writing on paper and doodling around.
* When I write, I drop into the passive voice too easily. I need to work at sticking to an active and consistent voice and write specific actions done by specific people rather writing from some omnipotent point of view.
* Sometimes I use long words when simple ones might serve better. It's a good idea to go back over near final draft and try to trim back the content by 10%
* The words "really" and "truly" are almost always unnecessary. Really! :-)
Have you ever noticed when you talk about "Refactoring" that your customer's eyes start glazing over? It's not surprising when you think about it. Martin Fowler defined Refactoring as "the process of changing a software system in such a way that it does not alter the external behaviour of the code and yet improves its internal structure". This sounds to a customer to be an aesthetic exercise in gilding the lily. Why spend time on beautifying the code if the current features are working? Wouldn't it be better to move right along and start work developing the next new new feature?
The word Refactoring does not do a great job of communicating what this activity is all about. In his book "Working Effectively with Legacy Code" Michael Feathers reminds developers that "code is your house and you have to live in it". This leads us to a better analogy for Refactoring that of Housekeeping, tidying up or in extreme cases Decluttering.
When I install a new feature in a room, you can understand that I will probably need to shift the furniture around. Suppose I buy a new chair for my living room, I need to create a space for it to sit in. I would typically do this by thinking about the current use of the furniture in the room. If a side table or set of drawers is rarely used then it becomes a prime candidate for moving upstairs or to the garage to make space. I may also need to move other furnishings around the room to accommodate my use of the chair. I want to have a reading lamp next to the chair, somewhere to put my coffee cup when I sit there, etc. Decluttering is reorganizing your stuff to make your home easier to live and work in.
Let's explore what Decluttering means when applied to code. When I create a new feature in software I have to find a place to put it, a code package roughly corresponds to room in house. Within that package, I need to review the existing contents to determine the best location for my new feature and what I will need to move around to accommodate it. In the software world, I am not truly constrained by space but if I just dump the code in anywhere then pretty soon I am going to find it difficult to find my way around!
The advice on Decluttering your home is to spend 15 minutes a day on this rather than let it build up. It's the same with code. Refactoring is something you do every day, a part of being a good citizen working in a collective workspace - you take out the trash, label new items clearly, and keep the pathways well swept.
If everyone on the team keeps on top of refactoring then it's rare that conversations about refactoring should come up with your customer. However, it's hard to be good citizen and when working under time pressure code can get messy quickly. It's after a period of working like this that the R word starts coming up in conversations with customers. Maybe at first as guilty statements "we probably ought to do some refactoring this iteration". A customer can translate this as clutter has built up in the code and it's starting to get in the way. Suppose the team decide to defer refactoring for a bit longer, the likely outcome is that they are slowed down in their work - it becomes harder to navigate and when code is spread out around the place there are more places that you need to edit to add new features. Deferring refactoring also has an impact on the good citizens, they may abandon their good practice because they are fighting an uphill struggle. Too many broken windows can start to have an effect on the whole neighbourhood. Programmers become depressed by the mess that they have to work around and feel their design skills are not valued.
One of the knock on effects of managers misunderstanding refactoring can be that it's not a big consideration when selecting tools to be used on a project (language and development environment). Providing programmers with integrated development environment with built-in refactoring support takes effort out of refactoring and makes it more likely that the team will keep on top of refactoring rather than letting things slide because tools they have require a lot of manual effort (sometimes the equivalent of a dustpan and brush).
Check out the definition of XP in the uncyclopedia could this be the XPv3? It's not all exageration - I actually worked on a project where the TW coaches had instigated the use of a pointy stick [a long bamboo cane with a cut out of a pointy finger on the end] :-)
Psychologist Ben Fuchs and my good friend, Joseph Pelrine, will be conducting courses in March on the Deep Dynamics of Agile Teams. Topics covered include
* Frameworks to understand teams as complex environments
* Characteristics of high performance teams
* Increasing team participation, innovation and creativity
* Effective interpersonal communication and feedback
* Working with conflict
* Rank, power and influence
* Evaluating teamwork
This course is relevant for anyone who leads and/or participates in Agile teams. More information.
I have to admit it, I hate comments, they annoy me. Why? I have hardly ever encountered a useful comment, they typically state the blindingly obvious and if not a little refactoring will usually make them redundant. The biggest problem is that comments are often out-of-date or downright misleading (having been cut'n'pasted along with some code and then not rewritten to match the new context). They clutter the code and get in the way of seeing the real structure of the code. I like to delete them.
However, sometimes you can get some useful insights from comments. I have noticed that developer gripes are sometimes revealed in comments and these can provide some useful insights. Here's an example from a project I worked on:
..Ideally this would be done as part of a lazy load implementation on the reference get method in each of the business objects. It would then use the DAO to find the objects it owns. Evectively implementing a manual version of container managed relations (CMR) in the Entity EJB world. However this is impossible thanks to our unconventional method of holding the database connection and passing from the top session layer down to the DAOs.
Consequently the only method of producing a complete tract object with all its children is to manually build the object here. Very nasty, completely against the idea of the DAO design pattern and the service layer seperatation, and very bad for maintenance.*/"
This comment told me that there was at least one developer on the team who still cared about the integrity of the design and that they felt like they were fighting a losing battle. I started to try to work with this developer to justify the much needed refactoring of the tangled dependencies to his architect/manager on the basis that this was a barrier to unit testing.
Some months later I had an email from that programmer "We started an 'on-going' refactoring of the code, which unbeknown to most, involved me sat at home for a couple of days ripping out all the initially developed classes and replacing the entire database connection system, manager system and xml adapter system."
I am not sure if there is a moral in this tale, perhaps that you find leverage points in strange places. In XP teams, it is important for programmers to feel empowered to make changes and the design should never be set in stone otherwise it weighs down the morale of developers. The refactoring in this story was the first step in lifting that weight.
A few weeks ago Jason Gorman a respected colleague sent me an email on the subject of Agile Foundations. Here's a quote:
It's high time we pinned some of these terms and concepts down, and made them testable (and therefore, measurable). I want to know what we mean by "being agile", so I can tell if a team really is "being agile", and if they're not "agile enough" I know which levers to pull to make them "more agile".
Subsequently, we had a long and rambling telephone conversation about this and other aspects of our agile consulting work.
The first point I made to Jason is that "Agile Software Development" is different to "agile" with a little 'a' and it's important not to forget the social aspect of it's construction.
Going back to it's roots, the term "Agile Software Development" came out of an effort to create some unity and deter in-fighting about lightweight methods. The founders of the Agile Manifesto were consultants who recognised that there was more in common between these methods than differences and that the real competition was waterfall development. The distillation of a common set of values and principles provided a method-neutral language that people could relate to and use to smooth over the differences. There neccessarily has to be some looseness in these principles to allow the different methods to wear the same agile clothes. The whole point of creating the banner "Agile Software Development" was to create an umbrella term so I don't believe it can easily be nailed down to a definitive set of measurable activities.
Agile Software Development also helped reframe how people looked at the specific methods. Before the creation of the Agile Manifesto people tended to focus on the number of artifacts and processes that defined a software development. The weight of the documentation was seen as a measure of a methods quality - from this perspective SCRUM and XP were labelled lightweight methods. Some of the lightweight methods had an edginess in their names that was a little scary to some people (being extreme suggests getting out of your comfort zone). Applying a new adjective "agile" was a great move - who wouldn't want to be agile?
Since my conversation with Jason I happened to re-read Jim Highsmith's "Agile Software Development Ecosystems" where he defines agility as "the ability to both create and respond to change in order to profit in a turbulent business environment".
This brings me back to my conversation with Jason, we have both encountered clients who translate "agile" in a software context to "do less work, go faster" and they may even infer "spend less money". Adopting agile software development is likely to have these outcomes eventually BUT any big change to how you develop software is likely to slow you down and cost money at the start. Coming back to Jason's concern (how can you measure agility), rate of developing requirements can give some indication of speed but the inner core of agility seems to be (as in Jim's definition) the ability to respond to change. This aspect of agility is harder to measure. And whilst you do want to adapt to changing needs, you don't want too much churn.
I believe at best you can only make coarse-grain assessment of the degree to which agile software development principles are applied in a project which can give you an indicator on where to focus process improvements. Measurements require a scale and I am not sure absolute numbers are meaningful in understanding what is going on in software projects - you need to take in the big picture and think about the dynamics of what you see.
I don't mean to dismiss the usefulness of metrics such as test coverage or earned value as an aid to process improvement - these can be helpful. However, Agile Software Development is the art of balancing between people, technical and business concerns not a mathematical equation. Numbers can inform our approach but they should not be used to define our destination.