Tuesday, February 24, 2004

Class Ownership #6 - Class Assignment Tip

As I’ve stated before, class ownership creates a constraint. The decision to use class ownership is a specific choice by a manager who wishes to achieve a higher degree of internal quality and accepts that the resultant constraint needs to be managed by subordinating all other decisions to the choice of constraint.

When assigning the classes to owners, some thought is required. Something we learned on the first FDD project in Singapore was that <<Moment-Interval>> classes, particularly key domain classes, must never be assigned to a chief programmer. For example, in a bank lending system, the class called ApplicationForLoan becomes a bottleneck. In a blogging application, the class called BlogEntry becomes a bottleneck. And so on…

For such classes, where you know there will be a high demand, you must choose a good strong developer who is preferably one of your fastest developers and most diligent with external and internal quality. However, you should not choose a developer who has communication responsibilities such as the chief programmers in FDD. Time spent communicating is time not spent coding. A key bottleneck class must be protected and the decision to assign an owner must be subordinated to other decisions. Hence, a chief programmer cannot be the owner of any of the most important classes in a system.

Monday, February 23, 2004

Chapter 2 at Inform-IT

Somewhat to my surprise, Prentice Hall have released another chapter as an article at Inform-IT - Chapter 2 Management Accounting for Systems.

Throughput Accounting [Corbett 1998] is a management accounting process that grew out of the manufacturing production application of the Theory of Constraints [Goldratt 1984]. Throughput Accounting can be generally applied for the management, control, and reporting of any system. It is a useful technique for management systems based on the Theory of Constraints, Lean Production [Womack 1991], Six Sigma [Tayntor 2002], or the Toyota Production System [Ohno 1988]. Throughput Accounting is appropriate for managing general systems because it focuses on Throughput, which is the desired adaptive behavior of the system.

Moving Constraints

It is often (and naturally) assumed that the constraint on software development is the ability to program code. If only code production was faster then everything would be fine - right? So all we need is more programmers - right? or as I discussed yesterday, better tools which partially or fully automate coding - right? Maybe! The reality is that coding isn’t as much of a constraint as people believe and that automating it will not deliver the significant gains that are anticipated.

Over the last 3 years or so, I’ve observed several projects and built up anecdotal evidence about how constraints move in a software organization. I haven’t formalized it yet so I haven’t written a paper about it. However, here is the anecdotal report [Note - as I suggest in the book, I am normalizing quality metrics using the Function Point concept]...

First the coding is the constraint and often this is because the developers are poorly organized and development is chaotic. As a result quality is often poor. Let’s suggest that 3 bugs per Function Point would be typical - perhaps worse. [Note: Capers Jones reports that 5 bugs per function point is about as bad as it gets in America. Around 1 bug per Function Point is CMM Level 2 quality falling to 0.15 bugs per Function Point at CMM Level 5]. When you introduce any method - production rate goes up - often by several fold. Suddenly, development is not the constraint but rather the quality assurance function. QA can’t produce full test coverage but bugs are found and development is once again the constraint whilst bugs are fixed. If you introduce more rigorous quality methods - typical of an agile method - then development once again improves and QA is once again the bottleneck. The answer is to increase the number of QA people. Strangely as quality improves, the number of QA people has to increase. With a very high quality development team, you may need a 1:1 ratio of testers to developers. As the QA function is elevated, test coverage increases and bugs found increases until eventually it levels out with full test coverage and quality better than 1 bug per Function Point.

At this point the developers start to starve for work to do. The constraint has moved forward in the process. It may have moved to architecture or analysis or UI design. The ability to feed the developers with input material has to be elevated. One way is to bring the business owners to the developers - as all agile methods advocate - and to reduce the formality of analysis work and increase the tactic knowledge or direct knowledge capture e.g. modeling requirements straight into UML as is typical with an FDD project. This may leave the constraint in the UI design group. This is where I prefer it.

However, what happens if you elevate UI design? Well the constraint tends to move to the other end of the process - the deployment or field operations unit, or down the value chain to consultants or systems integrators deploying the product. Elevating this may require better documentation, so more technical writers, or more adaptable code with a more modular architecture that is more customizable, or maybe quality is still insufficient with many bugs being found in the field through lack of proper production testing. However, if you fix all of these, where does the constraint move next?

It can go to the front or the very back of the process. At the front, the development organization is going too fast for marketing people to respond with a new product vision and new requirements - writing those MRDs or PRDs takes time. Alternatively, the constraint may move to the customer. The customer is simply not prepared to take new releases at the pace you are delivering them. This is a real problem because it means that the customer does not value your releases or your delivery lead time. Loss of value results which affects top line sales.

In Lean Production, the goal is a balanced flow where all the elements in a value chain move at the same pace. The TOC community differs from this view slightly suggesting that there must always be a single “drum” - a single capacity constrained resource (CCR) - in the system. Hence, it is “almost” balanced. However, the tools I mentioned yesterday disregard this concept. They seek to make one small piece of the value chain - coding - very fast. This will produce a limited benefit. Perhaps only cutting lead time by 20%-30% and resulting in less than a 100% improvement in throughput with only a small drop in work-in-process inventory. Only if almost (or full) automation is realized will there be a significant reduction in costs. Hence, if

Net Profit (NP) = Throughput (T) - Operating Expense (OE)
                        Inventory (I)

then automated coding tools will have a limited effect…

Net Profit (NP) = T*1.3 - OE*0.7
                        I*0.7

an approximate improvement approaching 100% might be a good guess.

On the other hand, end-to-end agile without fancy tools but rather a focus on people issues and discipline is likely to produce a 400% to 1000%improvement because agile methods allow the manager to deal appropriately with the moving constraint whilst a single point solution such as automation tool merely elevates a single resource which may or may not be capacity constrained.

Sunday, February 22, 2004

Intentional Automation

Following up from yesterday’s post, former Microsoft executive Charles Simonyi has clearly had his publicist working overtime. Not only did he get his picture in Business Week but an interview with him appears at News.Com (via Loosely Coupled). All this noise about his new company Intentional Software Inc. but apparently no product ready for another 2 years. Hmmm.

Simonyi claims that programming is the bottleneck (Ah ha! constraint language) and that this [bottleneck] needs to be eliminated through automation. The details here are somewhat nebulous but Simonyi appears to be talking about the notion of domain specific languages. Martin Fowler had something to say on this topic and how the OMG’s MDA might enable it.

The crux of this ties closely to the notion that the design is the information in an information system. The code is merely a translation or representation of that information. In Lean terminology coding is “muda” (waste), if only the design could be directly implemented. If you can have the domain or subject matter experts express their design in their own language then why not automate it from there? No need for human intervention. No signal to noise attenuation. No implementation level bugs - just design or domain bugs. Simonyi claims that 7 sigma would be possible with such a technique. Hmmm (again).

It’s a new paradigm! A new approach to software systems. It will require a new way of managing the lifecycle. From the wisdom of Eli Schragenheim writing in the Foreword of my book, “Once the limitation is vastly reduced, people should replace the old rules with new ones that take full advantage of the removal of the limitation. If this does not happen, then there is no added value…”. A new paradigm would require a new way of managing, a new way of working - perhaps even a new workforce.

I remain skeptical of purely technology based solutions. My recent experience has taught me that it doesn’t take a huge improvement in programming productivity to move the constraint somewhere else in the information systems value chain. At the point where the constraint moves, further improvement in the previous constraint has little overall effect - though it may reduce costs and improve ROI, it does not further improve throughput or shorten lead time.

[I’ll write more about how and where the constraint moves tomorrow.]

Saturday, February 21, 2004

Outsourcing Debate

In an interesting quirk of editorial timing the new print editions of The Economist and Business Week both have stories about outsourcing high-tech services jobs from America. The Economist points out in an editorial that this is nothing new and was to be expected and Adam Smith would approve, whilst there is a more in-depth piece against the backdrop of the US Presidential election in 2004 in the America section.

I’d love to link to the cover story of Business Week but they have hidden it behind a 65 cents per issue subscription login. What I love about this article is its accuracy and insight and understanding that the author clearly developed whilst writing it. So here are some poignant quotes from the hard copy…

“programmers ... must undergo the career equivalent of an extreme makeover. Traditionally, the profession has attracted brainy introverts who are content to code away in isolation. With so much of that work going overseas, though, the most successful American programmers will be those who master people skills.”

Right on! As I pointed out a while ago on Duncan Smeed’s weblog - it is way past time that a course in communication was part of a degree in computer science.

”Architects A few thousand tech visionaries sketch out entire systems to handle complex jobs… Outlook Outsourcing a non-issue.”
”Project Managers Crucial cogs in global software factories. They coordinate the work of teams in different countries and time zones and provide dependable products on schedule. Outlook Good managers can write their own tickets. Pay has jumped 14.3% in the past two years.”

The writing is on the wall - move up the value pyramid or suffer the economic consequences. [Note to self - discuss that 14.3% number with my boss]

In a related commentary…

“it’s especially important that corporations keep innovating in software development. One technique that was born in the late 1990’s is called extreme programming. In this approach, programmers work directly with business people breaking projects into pieces that can be written and tested fast. Pairs of programmers literally write code together simultaneously - creating real-time checks and quashing bugs as they go along. The technique is not yet widely employed, but it should be.”

Hang on there! Has Business Week just declared in an editorial commentary that American jobs can be saved if agile software development methods are more widely adopted? Wow!

Meanwhile, a doff of my cap to Kent Beck who has clearly built a very strong brand - no mention of “agile” in the article only “extreme” and Kent is actually quoted in the piece.