It used to be that I did not care much for defensive programming outside of a system’s boundaries. It used to be that I did not really care or believed in strict source control (as in authorise only some people to touch a particular file). It used to be that I did not really believe in code reviews.

I now care for these and it is not a good thing. I care about these things because I do not trust the developers I work with to do the right thing, whether it is making the code better, improving their style, teaching me new things, or even write descent unit tests.

No that I am perfect in any ways but I used to be able to trust people in the team to correct me and help me get better. I used to be able to trust people on the team to catch my mistakes and fix them.

Work is a lot less enjoyable when that trust is gone.

In the recent past I noticed an interesting property of self adjusting systems. They self adjust !

So when work in progress started to accumulate and stories ‘completed’ piled on the doorsteps of QA, production of new features essentially stopped. Granted, part of it was due to the number of bugs found. But given the level of energy displayed by the team, that was not the whole reason. Here is how physical systems work: when a pipe is blocked water stops flowing and typically an equilibrium is reached where water becomes stagnant at a stable level. When no equilibrium is reached it is called a flood.

Since then our team’s management has had a good idea, tell people what they were expected to finish by the end of the year. Not surprisingly, setting a clear goal energised people a bit and production has started again. Work in progress has tripled and the pile in on QA’s doorstep has doubled. Nothing short of normal in a two iteration period.

On the positive side we have the opportunity to get the development team rolling into the new year with the warm feeling of mission accomplished. Sure we now all know what mission accomplished means. It means there is a whole more work to be done before the work is actually done and delivered. But having a sense of accomplishment, given the tough economy and looming work force reduction, will be invaluable.

On the negative, let’s brace for a good month of flooding.

Joanna Zweig and César Idrovo have embarked on a journey to discover the coveted team jello, the thing that makes team jell. Best of luck to them.

Can’t wait to get a taste of it really !

I have just finished this book
this book by David J. Anderson and it was truly a breakthrough for me. It enabled me to go beyond the religious feeling of Agile to management science and why Agile methods work. Sometimes. It also lead me to finally understand what my company’s business is !

My book list just got longer by adding Domain Neutral Component, Theory of Constraint and Feature Driven Development to it.

And I encourage everyone to read the excellent CMMI-Agile article as well as another one on negotiations (both through David J. Anderson’s blog).

It seems incredible that the room picked for this talk was so small. As could be expected it was filled and overfilled.

I always seem to walk out of Kent Beck’s talks with mild disappointment. This is probably an effect of me expecting a full hour of breath taking and ground breaking material from him. The reality is that the material he presents is so refined (reduced to its simplest form but no simpler) that most of the talk is filling.

Building on previous work, he started with a definition of design and the influence of values (how do I evaluate the quality of a design) and principles (to some extend an operational effect of the values) on the design as well as the use of patterns.

Then came the core of the talk: design strategies. Kent Beck identified four design strategies from his experience. They are really strategies to evolve a design.

• First is the leap, jumping from one design to another in a single go.
• Second is Parallel, where the old design and the new one will co-exist for a while.
• Third is the stepping stone, whereby successive intermediary steps are defined and implemented before arriving to the new design.
• Fourth is simplification, whereby the design is made for a simplified version of the problem and then enriched by reintroducing the complexity.

I will craft examples around boat building to better explain what I understood. Leap would be to transform a sail boat into a motor boat by cutting the mast and adding a motor. Parallel would be adding a motor and when that motor works in a satisfying manner removing the mast. Stepping stone would be, starting from scratch to build a hull that floats, then add flooring and oars and verify the boat navigates, finally add a motor. The simplification would be to build boat that can navigate on a lake on a calm day, then enhance it to navigate on a stormy day, then adapt it to navigate close to the coast and finally adapt it to navigate on the open ocean.

I wonder if prototyping is also a distinct design strategy.

Anyway, overall a valuable talk from Kent Beck. Much better than last year’s or this year’s keynotes.

For those who arrived late that day (the day after the conference party), they missed the most important talk of the conference. See Martin Fowler’s reflection on it to get an idea.

For me it was a liberating talk. First because I had fallen into the habit of not thinking enough about storage, with the reflex of falling back to the familiar RDBMS type. And this is costing my current project a lot of time and effort. Tim Bray managed in fifteen minutes to break that idea by presenting the storage choices available at each point in the storage hierarchy.

For instance when you have to persist objects, why go to object relational mappings and RDBMS at all ? Why not use the file system directly ? As a side note, in my current project we did and had to revert to RDBMS because our system administrators could not make file system replication work !

The talk continued on with a very useful enumeration of the various alternates for each element of the persistence stack.

He concluded on performance comparisons between storage media (memory, networdked memory, solid state disk, disk and tape). And a quick review of the impact of the file system implementation on the disk performances.

A liberation I tell you !

This talk was primarily about how and why application teams (and their architects) have a hard time engaging enterprise architecture.

I will retain the single strongest thought of the talk: enterprise architecture is a stake holder of an application among a lot other stake holders. And the second strongest thought: enterprise architects are useful to bring a transversal view of a company’s technological portfolio.

The speakers went to great length to not antagonise enterprise architects and sounded at times as if it was a PR exercise (or maybe a rehearsal for a different public ?) to convince architects that agile teams are in a better position to support their goals than other structures (by giving them more visibility into the projects and giving them a say in what gets done).

I believe that half the talk was missing though: agile projects are stake holders in the enterprise architecture. In other words it is a two way road because the enterprise architects are technological enablers and therefore dynamic teams have an interest in influencing the architectural choices and the tools used to implement them.

All too often (I have three examples in the past couple of years), enterprise architecture’s choices have been embodied by inadequate product. The architectural choices were not contested (they were actually adopted or considered as a valid constraint). The solution was left to gather dust.

So enterprise architects, let the application teams help you help them.

And I have to admit I really like Martin Fowler as a speaker.

This was such an interesting talk. At least for those of us who are interested about what drives us developing software. As a side note this came up a few times during questions after Kent Beck’s keynote but the answers were rather less interesting being mostly about money and the good of humanity. This talk echoed with a lot of ideas I have been munching on for the past year about the philosophical make of Agile developers. I also have a rather keen interest for japan.

Dave’s talk was a crash course, impressionist, education in Zen philosophy, the arts ranging from the degree of enlightenment to the prowess that the fully enlightened and what it is that the disciple seek. I am not sure what the point of the talk was though. I think it was a warning that agile in software development cannot be the recipe of the day. It is a way of life, a path to enlightenment (in the Zen sense), in other words a quest for perfection through constant improvement. Although being a software developer is not as noble as being a monk, a warrior or even a sword craftsman.

Unfortunately, being that I am rather shy and I did not go to the conference parties I could not validate my impressions with Dave West and I have the impression it would have been a very long conversation. So please, if you attended this session, correct me ! I will write on this subject further in another post.

And by the way, should we talk about transcendence or immanence ?

Hopefully, if some day I actually manage a project (or worse manage developers) I will not forget this.

The amount of effort required to ensure developers are productive is bigger than the lost effort from slackers unless the team self polices. Also it is sometimes more productive to let a poor developer slack than to force him to do something that will eventually put him in the way of more efficient developers (see what Jay Fields had to say about that).

When there is no buy in from the team, if put under pressure, the first thing that will drop is quality because everybody knows that the clients will magically find money to pay for the bug fixes (or the support) that they did not have before for development.

It is good to prepare communication privately but it has to come out eventually. When communication is not forthcoming vertically it spreads horizontally with rumours and nags. Pretty soon instead of open and candid communication channels you have mistrust and scepticism.

It is good to read a management book once in a while just as it is good to stay technologically sound when you are a developer.

I obviously have no scientific base to support all that I have a bit of empirical evidence.

I will be attending QCon 2008 in San Francisco. If you happen to be there and you read this blog, I will happily give you a button proudly displaying the colours of this blog.

I will have one on my backpack.