Saturday, January 24, 2004

Class Ownership #2 - Preventing Atrophy

Code reviewing can be revealing! This can be especially true when done on a project which is a little unusual or run under stressed circumstances.

As I pointed out yesterday, class ownership introduces a constraint. When code needs to be written in a hurry, the class owner may not be available. There are two choices: wait for the class owner to free up; or allow a non-owner to check-out the class and make an update. When you are against the gun, there is little choice - break the class ownership constraint.

However, there is a price to pay. This price is not immediately obvious. In fact the systems cycle before it becomes an issue is so delayed and far removed that the cause and effect are hard to associate. Nevertheless, the quality of a class will atrophy unless the code is peer reviewed by knowledgeable team members. I found a great little example of this recently. A developer had opened another’s class and added a very short method to complete a sequence. The method directly accessed a member variable (private attribute) of the class. Elsewhere there was a friendly scoped accessor method. All the rest of the class was using this method. Why? Naturally, the class owner had a reason - in a future release of the software, the attribute would not be accessed but calculated by calling out over the object model to other classes. By accessing the variable directly a potential future defect was introduced. This would inevitably cause some head-scratching later on and it is unlikely that enough information would have been captured in comments or design documents to really explain why something was one way and something else another.

The point in this example is that here is one small isolated incident. When you allow anyone on a team (particularly a bigger team) to edit any class for any purpose, you will quickly lose design integrity of the class. Paul Szego calls this “losing the Zen of the class”.

It is truly important that classes themselves are considered components and that as such they are designed with the rigor which goes into larger components. This is best done by having one architect* for the component - one owner for the class.

[*Reference: Brooks, Frederick, The Mythical Man Month, Addison Wesley 1995, Chapter 4 Aristocracy, Democracy and System Design]

Friday, January 23, 2004

Class Ownership #1 - Team Think!

Feature Driven Development believes in class ownership - the notion that a named developer (or perhaps a primary and secondary choice) is selected to “own” a class. Only that developer will write code in that class. This creates a constraint and a potential bottleneck. Other agile methods do not believe in class ownership. My recent journey back to coding has reminded me why class ownership is important and I feel that a series of short blog entries is required. First up - Class Ownership Forces Teamwork!

Quite simply, class ownership necessitates the idea of a Feature Team. A virtual team which forms to design and build a small batch of Features which touch the same classes. Class ownership forces the owners to work together to design sequence diagrams and to agree the interfaces/method calls between the classes. This team thinking activity improves the quality of the design. It also improves the social and communication skills of the participants and helps them to build a camaraderie and mutual respect.

The alternative in many agile methods is one individual per Feature/Story/Task. This encourages the individual to design on their own. This leads to a poorer quality design (on the average) and valuable opportunities for team working are missed.

I was once (about 2 years ago) asked to assess a team I had recently met. They were doing some XP practices but otherwise it was chaos. My inquisitor was a psychologist. My response to his innocuous question, “What do you think of the team?” took him by surprise. My reply, “They are a group of individuals. There is no team.”

I don’t know whether the - one individual owns and is responsible for a feature and codes it from start to finish - was the only reason for this group work rather than team think, but I remain convinced it was a contributing factor.

Thursday, January 22, 2004

Manager as Permission Giver

Ever since I read The Tipping Point by Malcolm Gladwell, I’ve been toying with the concept of the role of manager as permission giver.

On pages 223 through 230 Gladwell talks about “Tipping People” - or permission givers. He uses very negative examples such as committing suicide and adopting smoking (as a teenager) but the concept can be applied positively too. People can tip the balance and cause a cascade of behavioral change through leading by example or giving permission. A line manager can act as this tipping person to change both the behavior of his staff but also the performance of his organization. The manager can change the culture by giving permission to change it.

Manager: Quality is poor! You should start code reviews before check-in
Developer: But we have no time to do code reviews!
Manager: I give you permission to take the time to do code reviews. Please start them.

Manager: Scaling this project is difficult. It takes too long to bring new people up-to-speed. You should produce design documents.
Developer: But we have no time to do designs!
Manager: I give you permission to take the time to do designs.

Manager: The design documents and finished code do not match. You should do design and code reviews.
Developer: But we have no time to do reviews and keep documentation in sync!
Manager: I will get you a tool which keep the code and design in sync. I give you permission to use the tool to the fullest of its capabilities. I give you permission to take the time to learn the tool and I further give you permission to take the time to perform reviews to insure that it is happening.

...and so on.

One big caveat to this “manager as permission giver”, is the idea that the line manager must have gained the right to give permission from more senior management. The more senior managers may not be “permission givers” themselves and hence, in order to change behavior, the line manager may need to pre-emptively up-manage the situation. I recommend doing this by painting the current reality, [In TOC language - the CRT or current reality tree], and then by showing a vision of the future reality [the FRT - or future reality tree] and then by presenting a series of actions to change the CRT to the FRT. It is important to get buy-off on this process and to ask that, whilst the change is happening, senior management does not interfere. Change always causes initial chaos. Things always get worse before they get better. In “Agile Management…” I refer to this as the J-Curve effect. Giving permission isn’t a magic cure but it is a good way to change a culture and to re-invent the mental model of the management in the minds of the developers doing the real work.

[If Phil Bradley is reading this - don’t worry Phil I bought a new copy of the book ]

Wednesday, January 21, 2004

To Code or Not to Code: Leadership versus Management

Recently I’ve been coding!

Back in the days when I worked at IBM as a contract coder - in the mid 1990’s - my line managers were both young and recently promoted to their first management job. The management training involved as many as 5 weeks away from the team and was referred to as “the brain washing” by the former colleagues (now staff) of the new boss. One of the key tenets which was drilled into these young managers was “thou shalt never code again”.

The position of line manager is key in any firm. The line manager is the one who manages the economic engine of the company. Without good line management, there is no business. The transition from individual contributor to line manager is also perhaps the most difficult and the most important for any business. For the first time, new line managers must learn to live vicariously through their staff. They must learn to coach the best performance out of their staff and to accept that some jobs will never be done as well as they would have liked them to be done or might have done themselves. This behavior of accepting life as a vicarious pursuit and learning to accept “good enough” rather than “perfect” is a measure of how well a manager is progressing and something on which further promotions to higher levels are measured.

It seems obvious then that if former developers are to learn to live vicariously, they must never code again. The temptation to “just do it” might otherwise be too great and they will never be good managers - always down in the noise and not defining the governing rules for their systems and the metrics with which to monitor and control them.

However, management is all very well but occasionally the troops need leadership. Developers need to be shown the way. This is particularly likely in new and uncertain territory. The greater the uncertainty - the greater the leadership required. Uncertainty can be caused by the domain - a new market being entered, or the technology, or the tools being used, or the working practices being adopted. In any or all of these circumstances, if the manager has the hands-on experience then it makes sense to lead by example.

When introducing FDD, for example, don’t be afraid to lead a Feature Team as Chief Programmer! Don’t be afraid to demonstrate how to Design-By-Feature by convening a Feature Team and facilitating the drawing of a Sequence Diagram! Don’t be afraid to hold a code review! When developers are unsure of how to implement behaviors such as “blue” <<description>> classes on a domain model, don’t be afraid to pair-program with a developer to make it happen. Pair programming is perfectly acceptable in FDD as part of the early lifecycle of a project whilst the architecture and design templates are being created. Don’t be afraid to fuzzy the line between Step 1 - Build a Domain Model and Step 4 - Design by Feature. It doesn’t matter if you have to go and build a dozen Features to prove a model. If seeing is believing then make your development team believe. Lead them to belief through example. Don’t let “analysis paralysis” bog you down. Don’t let subjective debate and belief cost you inertia and velocity. Lead by example.

It is OK for managers to code when they are leading! Once momentum builds and the team feels comfortable then the manager can quietly slip back into the vicarious life of monitoring metrics.

Tuesday, January 20, 2004

Where are the Historians?

As a follow up to yesterday’s post, I’m wondering where the historians are in software engineering? Is anyone undertaking to write the history of our profession? If you know please post to the comments? I genuinely hope someone has thought about this.