Saturday, February 28, 2004

Embrace Transparency - the Antidote to Offshoring

A good thread at Joel Spolsky’s Ask Joel forum, is discussing, offshoring. What’s really interesting about this is the amount of opinion without much in the way of objective data. The guys who mention cost as the motive are on the right track. The real problem is that the industry isn’t measuring the right things and making an objective assessment of offshoring is difficult when there is a lack of information in the (software development) economy. What’s missing is data on lead time and client-valued functionality produced.

Quoting from the 3rd sentence in my book, “Senior executives, perplexed by the spiraling costs of software development and depressed by poor results, poor quality, poor service, and a lack of transparency are simply shrugging their shoulders and saying, ‘if the only way this can be done is badly, then let me do it badly at a fraction of the cost.’”

Rather than argue, that design can’t be separated from coding - because no one who isn’t in the software business will believe you - and even some that are won’t believe you either - [Different parts of a design have different levels of uncertainty, not all parts of a system are truly unknown until the code is tested. Ref: Donald Reinertsen, Managing the Design Factory and some other pieces at this site including Separation of Concerns.] - instead developers must embrace transparency.

When executives have all the metrics - the throughput (or production rate),  the work-in-process inventory, which is directly proportional to, the lead time (the process flow time to complete working code) which is a direct input to, the rate of depreciation of the design/ideas inventory, and leads to a depreciated net present value for projected revenue, from dollar values associated with sales made/(or lost) through faster/(slower) delivery, together with the working capital required to fund less/(or more) work-in-process - only then can they make informed decisions about offshoring. While executives only have cost metrics, they will continue to make sub-optimal decisions. It’s up to development organizations to learn to measure the right things and to report them transparently to the top of the organization. This will allow offshore facilities to be measured by the same yardstick. It isn’t enough to subjectively argue that a subject matter expert in Chicago and a developer in Bangalore will take longer to produce a product with lower quality than when the two of them are in the same room together in New York. You have to supply the objective metrics to back the argument.

Quoting the 5th and 6th sentences from my book, “Software development has to cost less and produce better results, more reliably, with better customer service, and more transparency. This book will teach the agile manager how to achieve that.”

Friday, February 27, 2004

Class Ownership #7 - Does it Work?

This old but good thread at the FDD community site discusses how effective class ownership can be. I particularly liked this comment from Jeff De Luca.

If you do not use class ownership, when you assign a feature to someone then they must touch four classes (for example) in the system. They must have knowledge of four classes in the system. Think of very high use classes - such as LoanApplication in a Lending system. There would be a class with dozens of methods and attributes each written by a different person at a different date and time!!! (if not using class ownership)

Encapsulation is one of the founding principles of objects and is about a class being able to hide how it does what it does, and vary how it does what it does as long as it preserves its interface to all other objects. Well, class ownership naturally fits this fundamental requirement of objects. With class ownership you get better consistency of implementation and better consistency of interface.

Thursday, February 26, 2004

Package Ownership

Here’s a suggestion for a new meme in FDD style projects - the Package Owner.

A Package Owner would be a Chief Programmer. The responsibility of package ownership is to take responsibility for the API/SPI of the package. To full understand its responsibilities as a larger-grained component and to hold the domain knowledge of its public interface. No one else on the team is allowed to change the public interface of a package, whether class or method, without the package owner’s approval.

Package ownership, just like class ownership is all about maintaining internal quality and integrity. It’s about developing coherent libraries which are maintained overtime and continue to make sense. Its about good OO design.

Can we take this meme up another level and declare distributed component owners? or component owners? Chief Programmers or Architects who take responsibility for the service-oriented interface externalized from a distributed component such as a SessionBean? More on this another time…

Wednesday, February 25, 2004

The Case for Class Ownership

Four of my recent blog entries [1, 2, 3, 4] grow up to become an article at the Borland Developer Network in my latest Coad Letter #118: The Case For Class Ownership.

Feature Driven Development (FDD) [Coad 1999, Palmer 2002] believes in class ownership - the notion that a single named developer (and perhaps a secondary deputy) 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. Class ownership is a deliberate choice. In the language of the Theory of Constraints [Goldratt 1990], it is a policy constraint. FDD has chosen to adopt class ownership as a constraint, whilst other methods have chosen to eliminate it by abolishing such a policy and allowing any developer to make the necessary changes in any class. On first observation, the elimination of a policy constraint such as class ownership would appear to allow development to happen faster and for development work to flow more easily. The decision to adopt class ownership was not made lightly and its continued use after almost 7 years of FDD is worth discussing. Class ownership is a choice. It is for individual managers to decide whether that choice is right for them and their organization. With this article, I hope to illuminate some of the reasons why FDD practitioners believe that class ownership makes sense.

[Download in PDF ...]

Chief Communicator

It’s been written in several places how the Chief Programmer and Feature Team model in FDD were inspired by the surgical team model of Harlan Mills and advocated by Fred Brooks in The Mythical Man Month. It is worth a few lines to explain why the word “inspired” is so carefully chosen.

In Mills’ surgical team model, the chief programmer is the surgeon and does all the programming. The rest of the team support the surgeon and keep him (or her) productive. This is very much a military style model - the 1:6 frontline troop:supply chain support troops ratio where it takes 6 soldiers to keep a single one fighting at the front. The argument for Mills’ model is that one great developer is probably a 10x performer and hence it is worth spending resources for 5 or 6 people to support that.

In FDD, the Chief Programmer plays a different role. It is a role of communication but also leadership and design expertise. A Chief Programmer is a chief communicator. Communication happens within Feature Teams and is channeled through the Chief Programmer between Feature Teams and other people on a project. FDD is self-organizing at the Chief Programmer level because only the Chief Programmers are doing the project-wide communication. The other developers are Class Owners. They focus only on their classes and collaborate and communicate (generally) only with owners of other classes affected by the same Features in their current Work Package.

FDD seeks to get a performance improvement by elevating the individual developers by keeping them busy and uninterrupted. Chief Programmers absorb that communication on their behalf. It’s a different formula than that of Mills’ but its intent is the same - higher productivity.