Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Code is Liability, the Less the Better
Posted by Vikas Hazrati on May 18, 2011
In lean manufacturing, the definition of inventory is pretty clear. It is the extra material, work in progress material and material queued up for the next bit of work. Lean emphasizes on reducing the inventory because there is always an inventory handling costs. In software development, often requirements are seen as inventory, what about the code?
If you spend a lot of time elaborating requirements for features you are not going to work on for a while your process isn't streamlined enough. That's fair, but I think that the brutal reality is that we have something much more tangible that we can see as inventory: our code.
According to Michael, in Lean manufacturing, components are made one by one. Real efficiencies can be gained by streamlining how the pieces go through the process. Things are different in software. Here teams are working on the same piece again and again. It is not quite done till the system is being used. Hence, code is a live inventory that we carry through and it needs to be minimized.
In software development, we are essentially working on the same car or widget continuously, often for years. We are in the same soup, the same codebase. We can't expect a model based on independence of pieces in manufacturing to be accurate when we are working continuously on a single thing (a codebase) that shows wear over time and needs constant attention. No, to me, code is inventory. It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.
Likewise, Ori Pekelman suggested that code is a liability than an asset. Initially teams would have to write code to make the product which would fetch money, however later, teams should find ways to reduce the code as much as possible to keep the costs low. According to Ori,
The more code you have, the costlier it will be to add anything new. And the real bad news is that everything you add will just pile up on top of the "code that is" making every subsequent addition even costlier. Now the negative marginal utility of the existing code is not a fixed quantity : the better structured you code is, the more unit tests you have, the more cool schema-less or loose schema databases you use, the less new code is costly.
In the book, The Art of Readable Code by Boswell and Foucher, the authors stressed on the importance of lightweight code bases. According to them, the best way to cope up with a production system is to keep the codebase as light as possible. Some of the ways suggested were,
- Create as much generic utilities as possible.
- Remove unused code or unused features.
- Keep project modularized into disconnected sub projects.
- Be familiar with the libraries around you.
- Always be conscious of the weight of the codebase, keep it light and nimble.
Kevlin Henney mentioned a strong need to remove code and make it lightweight as a possible in his practical guide to writing less code.
Thus, there are strong reasons to keep the codebase light and nimble. As Michael aptly summed it up,
I think that the future belongs to organizations that learn how to strategically delete code. Carrying costs are larger than we think. There's competitive advantage for companies that recognize this.
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Five Key Practices to Agile ALM
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agile Maturity Model Applied to Building and Releasing Software
Related Sponsor
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Recommended reference to lean software development
by
Joseph Chen
Posted
Re: Recommended reference to lean software development
by
Joseph Chen
Posted
Never compare Software Development with Manufacturing
by
Roopesh Shenoy
Posted
Re: Never compare Software Development with Manufacturing
by
Vikas Hazrati
Posted
Re: Never compare Software Development with Manufacturing
by
Roopesh Shenoy
Posted
Re: Never compare Software Development with Manufacturing
by
Cloves Almeida
Posted
-
Mary Poppendieck's, www.poppendieck.com/, "Principles of Lean Thinking" in 2002 is probably the first article discussing the concept of Lean in software development. Interested readers are welcomed to check out the article at www.gregoryneilassociates.com/articles/lean_thi.... The article has a much complete illustration of lean software development.
-
CIO magazine happens to have another interesting article related to lean product development, commented by Steve Jobs at Apple, at www.cio.com/article/682517/Steve_Jobs_Told_Nike....
-
I never preferred comparing any aspects of Software development to Manufacturing. Don't get me wrong, I 100% agree with lean code built through short cycles of development, but the comparison to lean manufacturing is somewhat misleading. Though both are beneficial practices, lean code is meant primarily for agility and then for cost reduction whereas lean inventory is mainly for cost reduction. Also, value of inventory is proportional to the amount of inventory, whereas for lean code, there may be upfront investment required (for several refactorings, for eg) to actually reach and maintain a lean state.
It would be really dangerous if the suits start taking more leaves out of manufacturing and start applying them willy-nilly to software development. I have seen it happen, and giving these examples only make them stronger in their beliefs that yes, developing software is indeed similar to manufacturing.
A much better comparison is always RND effort that goes before manufacturing. -
>It would be really dangerous if the suits start taking more leaves out of manufacturing and start applying them willy-nilly to software development. I have seen it happen, and giving these examples only make them stronger in their beliefs that yes, developing software is indeed similar to manufacturing.
I guess that is what Michael suggested through the quotes mentioned above. Manufacturing and software development _are_different because we do not work on pieces in a process. Not sure, if you meant the 'Code is inventory' analogy is wrong/misleading? -
The analogies get applied in deadly ways. A statement like 'Code is inventory' will make non-tech people think that getting lean code out is cheaper - (hey less code should cost less than more code, isn't it?! That's the way inventory works!!)..
rather, it takes time to refactor things and move things around and hence it takes more effort and more time. The only time it saves cost is **AFTER** doing it (during subsequent). Try explaining how this fits into the manufacturing analogy.
This is just a simple example, wait till you see really creative suits who think they know-it-all read this. I am sure some poor development team is going to suffer because their manager will read this article and remember only "lean software development is like lean manufacturing" and forget everything else mentioned here and say..
"Come on people, lets get lean!"
:)
But overall I agree that in most cases, the emphasis on keeping code size down is really important. Kudos to bringing that out. -
Lean has nice concepts and techniques that were developed to be applied in manufacturing. While some might apply software development, current agile body of knowledge has it better.
Let's see:
>> Create as much generic utilities as possible.
Don't Repeat Yourself. Yet, this mostly breaks the You're Not Gonna Need It principle.
>> Remove unused code or unused features.
One aspect of Refactoring. If you know how to use a version control system, you don't need unused code lying around.
>> Keep project modularized into disconnected sub projects.
Separation of Concerns. Again, do it earlier in the project only if you're really gonna need it!
>> Be familiar with the libraries around you.
Don't be a moron and keep yourself informed the craft you've chosen to make a living.
>> Always be conscious of the weight of the codebase, keep it light and nimble.
Refactor frequently.
Lean techniques, if applied without very much prior thinking will get you burned. It's hard enough to apply on the relatively static field of manufacturing, it's much harder at the very dynamic field of software development.
6 comments
Watch Thread Reply