Tuesday, May 25, 2004

Management vs. Financial Accounting

It’s a commonly held misconception that my book has a heavy focus on financial accounting for software engineering. The root of this misconception is in the difference between management accounting and financial accounting. The two are not the same and for good reasons.

Financial accounting is something performed to agreed standards and principles (GAAP) designed to fairly and accurately report the true worth of a business to its owners and its true profits to the tax collector. Management accounting, on the other hand, is a mechanism for using a financial metric (dollars) as a normalizing mechanism for making decision about (often vastly) different choices and alternatives. Management accounting helps you decide whether it is better to add 900 customer account advocates in a call center in Ireland, against staffing a user experience and technical writing department in St. Louis, MO, and investing heavily in intuitive products. Management accounting helps you make decisions. It helps you to do the right thing.

Hence, my book does use management accounting as a mechanism for evaluating the merits of different aspects of the software project lifecycle and different styles of development process. The Throughput Accounting model in my book is designed to help you make decisions, for example, should you invest more in requirements, or spend more on development?

To really emphasize that management accounting has nothing to do with financial reporting, Eli Goldratt in The Haystack Syndrome, introduced a metric he called DollarDays. This is the multiplication of the value of inventory held by the number of days it has been held. Clearly, DollarDays has nothing to do with the financial worth of the inventory. It does not double in value every few days. The purpose of DollarDays is to underscore a simple lesson - holding inventory is bad practice! By using a DollarDays metric as a replacement for Investment, it makes the ROI on slow turning inventory look very bad. The purpose is simple. Amplify the valuable information and improve the signal to noise ratio from management accounting.

We could try something similar in agile development. How about StoryPointDays - multiple of the number of WIP Story Points by the number of days they have been in development - or in FDD, FeatureDays? The target would be to minimize the number. Each team in a larger organization could report its FeatureDays score each day. Management could see at a glance whether the team was making a good job of keeping batch size (Chief Programmer Work Package) small and lead time short. The lower your StoryPointDays score, the more agile you are!

Monday, May 24, 2004

YAGNIITIOR

You Aren’t Going To Need It In This Iteration Or Release!

Following up on yesterday’s post on refactoring, I’d like to characterize FDD’s approach to the XP practice of YAGNI. To use XP terminology for a moment, FDD has an architecture spike at the beginning - build a domain model - followed by a planning spike - build a Feature List followed by a loose scheduling process which accepts variance and uncertainty. Only then does the hard work of design and coding begin - typically one week into the project rather than one hour or one day.

FDD is saying that investing up to one week to gain information about an iteration or release is worth it. In other words, there is a return on investment due to reduced refactoring. Hence, FDD does not follow the YAGNI rule on a per Feature basis. Instead it says, find the simplest thing which makes sense for the whole iteration - based on the architecture work and modeling done in the first week - and build that. Does that mean in week 2, you might be building a class which is needed in week 4? Yes, it does! Isn’t that risky? No, it isn’t! Unless you are living in a world where the requirements suffer significant change and the business model of the customer changes at such a rate that the half-life of the requirements is less than a month, then it is not risky to build code which was identified during the initial architecture spike or domain modeling.

Sunday, May 23, 2004

FDD and Refactoring

It’s funny how life can have its little coincidences. There has been a fairly active conversation in my Yahoo! group about how to deal with refactoring and whether or not it constitutes “dark matter” which should be tracked on the Feature List and on the Cumulative Flow Diagram. Similar questions have been asked over at Jeff De Luca’s site this month. It may take several blog entries to fully cover this topic but here goes for the first one.

As Jeff says in his reply refactoring seems to mean many things to many people. Brad Appleton has pointed out to me that Martin Fowler is now using two terms - refactoring and restructuring. Refactoring is the idea that as you grow an architecture and add classes and methods, you have to make changes to existing classes and methods and the tests which validate them. These changes are small and are more like adding associations and perhaps changing method signatures. Then there is restructuring which is outright changing of the model because it couldn’t cope with a new requirement.

So first let me say that I wholly agree with Jeff De Luca’s opinion, that refactoring to use this new and refined definition, is “business as usual” for FDD. FDD embraces the idea of refactoring without making a song and dance about it. Refactoring is part and parcel of the Design-By-Feature activity and any refactoring of code and tests needed on existing classes would be hidden as part of the Build-By-Feature activity. There is no need to show this as additional Features and it is not “dark matter”.

Restructuring on the other hand, for example, taking a class inheritance hierarchy and reorganizing it using <<Role>> classes using object inheritance to provide additional flexibility and re-use, that would be rework of existing code which is already credited in the earned value percentage for the project or the in flow of value recorded on the cumulative flow diagram. Such a change, even if it gets called “refactoring” would definitely want to be identified as “dark matter” and listed on the Feature List of the project. Why?

Figure 1. Class Inheritance for Bank Account Borrowing and Depositing

Simply put, restructuring represents rework which eats into the productivity of the developers. It reduces the velocity on the visible client-valued functionality. If restructuring remains hidden and invisible then it simply makes the team look slower. However, if the restructuring is surfaced as a Feature and there is transparency on it, then questions can be asked. Why is this restructuring taking place? What is its value? The answer might be simple. I want to restructure the class hierarchy in order to make re-use out of what is current a sub-class.

Figure 2. Object Inheritance for Bank Account Borrowing and Depositing

In the example shown in Figure 1 and 2, the behavior associated with borrowing and depositing money from/to a bank is restructured into an object inheritance model using <<Role>> classes. This allows the Depositor and Borrower behavior to be reused by both the individual Person class and the corporate Organization class. Hence, the restructuring is being justified on the grounds of re-use.

Note that this restructuring probably has a payback. The “dark matter” Features for the restructuring work may have an immediate impact because Features associated with borrowing and depositing by an Organization may be dropped from scope or replaced with the restructuring Features.

Friday, May 21, 2004

Revealing Dark Matter

I’ve talked about “dark matter” before - emergent Features which are missed in the initial Feature List analysis but discovered as the team gets into the Design-By-Feature, Build-By-Feature cycle. Dark matter is not scope creep a.k.a. change requests - those should be plotted differently. I thought I’d show you an example. In this diagram, initial scope starts to fall as Features are pushed from the current iteration to a future iteration. The team gradually discovers that the customer didn’t really need those features at this time. Meanwhile, their own analysis gradually reveals the dark matter. These previously hidden features get added to the feature list and plotted as part of the Feature Inventory in a Cumulative Flow Diagram [see the CFD for the same project]. Then a change request arrives. It is modeled and sized and it too is added to the overall scope. Later it is discovered that this change isn’t really needed until much later and it is dropped from the Feature Inventory for this iteration, being placed into the future feature backlog.

[Update: There has been a longer, deeper thread of discussion on this topic in the agile management Yahoo! group]

Thursday, May 20, 2004

XP as Vanguard of the Revolution

My blog on Tribalism seems to have caught the attention of at least a few notables from what they want to be known as the “XP School of Thought”. My intent with the piece seems to be misinterpreted by those who see it as critical of XP. So now it is time to give credit where it is due.

eXtreme Programming deserves credit for its leadership - for its role as vanguard of a revolution. I’m sure that Kent Beck, Martin Fowler, Ward Cunningham, Ron Jeffries and others did not set out to create a cult, tribe or religion. Their intent was to preach a better way of building software and to show that software development could deliver value and delight customers.

Where XP seems to have scored is with its attractiveness to developers. It appealed to their psyche. It is almost a side-effect that it happens to be more productive in many circumstances. It was XP which gave the agile movement momentum. In the popular press, such as Business Week, you never see “agile” mentioned, you see “extreme programming” used as synonymous with the whole agile movement. The enlightened amongst us know that is wrong. But in my view it is all right. If the wider world wants to call it XP because it gives them a handle with which to grapple then that is fine. I’m not in love with a brand. Like many other thought leaders in this space, what I want to see is a more economically effective software industry.

In the longer term, political devices such as polarization of a debate amongst artisans or intellectuals will fade. There is no need to demonize an enemy when the enemy is already you. So too will branding of prescriptive solutions. What will prevail will be the lessons and the principles. We are only just beginning to get to grips with these, to abstract out from the prescriptive solutions what is truly useful. I believe that this shows a growing maturity. Perhaps we can leave blind faith and tribal affinity behind and adopt a more scientific approach to achieving the goal of more economically effective software production.

In years, or probably decades, to come, software developers will accept the humanity in knowledge work as a basic tenet and understand that to compensate for human frailty it is necessary to do things in small batches, focus on high quality and highly effective communication. All of these things will be taken for granted. At the root of this revolution in how software is done, will have been eXtreme Programming , first and foremost and above everything else that was once called “agile”.