Write Less Code


If we were to look for the root cause of waste in software development, a really good candidate would be complexity. Complexity calcifies our code and causes it to turn brittle and break. In Conquering Complexity in Your Business, Michael George suggests that complexity is like cholesterol: It clogs up the arteries of an organization; it is "the silent killer of profits and growth.[1] The prescription for complexity in software development is simple: Write Less Code!

[1] Michael George and Stephen Wilson, Conquering Complexity in Your Business: How Wal-Mart, Toyota, and Other Top Companies Are Breaking Through the Ceiling on Profits and Growth, McGraw-Hill, 2004.

Let's take a look at how a multibillion Euro company has gone about doing just that.

Zara

When Madonna gave a series of concerts in Spain recently, the outfit she wore at her first concert could be spotted on teens in the audience at her last concert. The Madonna look-alike outfits were purchased at Zara, a rapidly growing fashion clothing chain. Zara's strategy is to be a fast follower, betting that it's more profitable to develop the fashions its customers ask for than to push new designs onto the market. In the rapidly changing world of fashion, a fast follower has to be very fastZara can go from concept to cash in two weeks; entirely new lines might take a month.

Zara accounts for perhaps 70 percent of the sales of Inditex, a clothing company located in western Spain with over €5 billion in annual sales. Zara competes fiercely with Stockholm-based H&M, Venice-based Benetton, and San Francisco-based Gap and posts some of the healthiest profits in its industry. It has close to 900 stores as of this writing, about three-quarters of them in Europe, and is expanding rapidly.

Instead of hiring high-profile designers to create new products for each selling season, Zara hires the best graduates from design schools and has them work with store managers to create the garments that customers are looking for. Zara launches 11,000 new items a year, compared to its competitors' 2,000 to 4,000.[2] Zara stores are lightly stocked. Orders are sent to headquarters twice a week, and the clothes arrive two or three days lateron hangers, priced, and ready to sell. Zara eschews economies of scale and manufactures in small lots, usually in cooperatives in western Spain. It operates well below capacity so as to be able to maintain its ability to fill orders twice a week even during peak demand.[3]

[2] Data from "Inditex: The Future of Fast Fashion," The Economist, June 18, 2005.

[3] Kasra Ferdows, Michael A. Lewis, and Jose A.D. Machuca, "Rapid-Fire Fulfillment," Harvard Business Review, November 2004.

Zara gets more revenue for its efforts than its competitors: It sells 85 percent of its stock at full price, compared to an industry average of 60 percent to 70 percent. Unsold items account for less than 10 percent of sales compared to an industry average of 17 percent to 20 percent.[4] Zara also spends less money than its competitors: Zara's parent company, Inditex, spends about 0.3 percent of sales on advertising compared to a 3 percent to 4 percent industry average. And it spends perhaps 0.5 percent of sales on IT compared to an industry average of about 2 percent.[5]

[4] From "Rapid Fire Fulfillment," Ibid.

[5] Andrew McAfee, "Do You Have Too Much IT?" MIT-Sloan Management Review, Spring 2004.

Stop. Let's go over that one again. A €5 billion company spends 0.5 percent of sales on IT? Indeed, Inditex's IT staff of about 50 people develops all of its applications. Stores use PDAs and a modem to transmit sales totals and new orders to headquarters. Instead of a CRM system, designers are expected to talk to store managers. And with such low inventories, an ERP system would be overkill. Interestingly, the CEO who orchestrated this minimalist approach is a former IT manager.[6]

[6] From "Do You Have Too Much IT?" Ibid.

In "Do You Have Too Much IT?"[7] Andrew McAfee lists five principles that guide Inditex's use of technology:

[7] Ibid.

  1. IT is an aid to judgment not a substitute for it. Information systems help managers sort though the data they need to make decisions, but they do not make decisions for people, or even suggest them.

  2. Computerization is standardized and targeted. Stores and regions are not allowed to deviate from the single corporate solution, and developers minimize system features rather than maximize them.

  3. Technology initiatives begin from within. Business goals always shape the company's use of technology, not vice versa. The IT department works with line managers to understand their needs, and only then do they look at available technology to find solutions.

  4. The process is the focus. The store's PDAs are not "personal productivity devices" for managers. They support the daily cadence of sales reports and the twice-weekly cadence of orders and shipments. They enforce a consistent process across all stores.

  5. Alignment is pervasive. It helps to have a CEO who used to be an IT manager, but business-IT alignment takes much more. The business people and technology people really understand each other's worlds. There is no we-they divide and no over-the-wall software.

Complexity

Just about every start-up company with a single software product is nimble and can quickly respond to customers and adapt to change. But after a couple of years of success, software companies often start to slow down and become unresponsive. They have developed a complex code base, a complex array of products, and a complex organizational structure. Unless they get the complexity under control quickly at this point, it will gradually strangle the very responsiveness that gave the company its initial competitive advantage.

The cost of complexity is not linear, it is exponential, and the cost of complexity eventually comes to dominate all other costs in most software systems (see Figure 4.1). Complex code is brittle and breaks easily, making it almost impossible to change safely. Wise software development organizations place top priority on keeping the code base simple, clean, and small.

Figure 4.1. The cost of complexity is exponential.


Justify Every Feature

The first step to controlling complexity is to aggressively limit the features and functions that make it into the code base in the first place. Every feature that gets developed should pass the hurdle of proving that it will create more economic value than its fully loaded, lifecycle cost. Loading software products with a laundry list of features is the lazy approach to marketing: We don't know what customers will value, so we put in lots of features in hopes that customers will find some things they like. But loading software with features is worse than just laziness; it's a recipe for disaster. Software is complex by nature, and unless that complexity is carefully managed, it rapidly grows out of control.

It takes courage to limit the feature set of a development effort, but it almost always pays for itself many times over. In the product world, launching a product with just the right features, no more and no less, demonstrates that the company really understands what customers want. This was Intuit's strategy when it launched QuickBooks. Intuit realized that very small businesses did not want software designed for accountants, and so it developed a product that did not even have double entry bookkeeping, something its competitors considered fundamental. Intuit understood well who its customers were and what job they were trying to do, and delivered only the capabilities that its customers were looking for.

Jeff Sutherland, CTO of PatientKeeper (a company we discuss in Chapter 5) emphasizes that developers should not develop any feature until there is a well-defined market demand. He says:[8]

[8] Posted on object-technology@yahoogroups.com on March 11, 2003, Message 121. Used with permission.

The task then is to refine the code base to better meet customer need. If that is not clear, the programmers should not write a line of code. Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won't be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.

Minimum Useful Feature Sets

Whether we are developing custom or product software, the ideal approach is to divide the software into minimum useful feature sets, and deploy these one set at a time, highest priority (or highest payback) first. A minimum useful feature set is one which helps customers do a useful portion of their job better. While there are environments in which an all-or-nothing approach might seem like the only way to proceed, this is rarely necessary either from a technical or from the customers' job point of view.[9] We have been conditioned to think that the large-batch, all-or-nothing approach to software development is good. It's time to recondition ourselves to think that this is the worst possible approach to good software development.

[9] Games are a notable exception.

Deploying small, useful feature sets in a custom development project allows customers to start using the software much faster. When these feature sets start generating a return on investment earlier, the company can invest less money, payback the investment sooner, and, usually, generate more profit over the life of the system.[10] Technically, implementing minimum useful feature sets is not only practical, but when done correctly, the code is refactored and simplified with each new feature set. This helps minimize the complexity of the code base, thus minimizing its lifecycle cost. From a customers' viewpoint, receiving minimum useful feature sets means getting their job done sooner and finding out how they really would like the software to work while there is plenty of time to ask for changes. And from a sustainability point of view, systems implemented incrementally with minimum useful feature sets are usually easier to maintain because incremental development can be extended over the life of the system. There is nothing not to like about implementing software in minimum useful feature sets.

[10] See Mark Denne and Jane Cleland-Huang, Software by Numbers: Low-Risk, High-Return Development, Prentice Hall, 2004.

Don't Automate Complexity

We are not helping our customers if we simply automate a complex or messy process; we would simply be encasing a process filled with waste in a straight jacket of software complexity. Any process that is a candidate for automation should first be clarified and simplified, possibly even removing existing automation. Only then can the process be clearly understood and the leverage points for effective automation identified.

"Our Company Is All About Complexity"

At a recent seminar, one of the value stream maps (described later in this chapter) depicted a software ordering process rather than a software development process. As we analyzed the map, we saw that about half of all orders had to be revised, often after they had gone through an arduous customer approval process. The delay and changes caused by the error-prone process were creating a lot of unhappy customers and slow deliveries.

"So why aren't you looking for these errors earlier? Why wait so long?" I asked.

"Well, there are a lot of reasons," explained the person presenting the value stream map. "Often the problems are time related. The order was OK when it was submitted, but time passed, contracts expired, and so the pricing or the terms changed."

As we delved deeper, it was clear that the order processing group was expending heroic efforts to get the orders right, but the pricing structure was so complex that it overwhelmed them.

"Maybe you should look at your pricing structure," I suggested. "It seems extraordinarily complex to me."

"Oh, our company is all about complexity," came the immediate response. "We just revised our pricing structure, and the objective was not to make it simple; the objective was to optimize the amount of revenue we get from every customer."

I suggested that with all the problems we saw in the value stream map, the extra revenue was probably eaten up several times by the complexity.

"Not only that," someone agreed and then elaborated, "the new pricing structure is a compromise that no one likes: not customers, not order processing, not even sales."

Even though the order processing problem itself was very large and very visible, until that moment, no one had traced the underlying problem to its root cause, because no one had been conditioned to think of complexity as bad. In fact, the solution under consideration was to create a computer system to manage the complexity.

I suggested that the process needed simplification, not automation, because if they automated the current complexity they would be casting it in concrete, and that would probably prevent them from ever simplifying their ordering process.

Mary Poppendieck





Implementing Lean Software Development. From Concept to Cash
Implementing Lean Software Development: From Concept to Cash
ISBN: 0321437381
EAN: 2147483647
Year: 2006
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net