« The Urge to REPL, the Urge to Test | Main | UML Out of the Box »

May 17, 2011

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341d798c53ef0154325e868d970c

Listed below are links to weblogs that reference The Carrying-Cost of Code: Taking Lean Seriously:

Comments

Pawel Zubkiewicz

@Alex Skorulis the idea is to rewrite code in such way that you will understand what the code does, next time you look at it.

Of course in many cases you will also need some business documentation to refresh your understanding of business context (why my code does that? do I still need it? and not only how it does?), because many enterprise systems have big Essential Complexity.

Chris Matts

Lovely post. Nat Pryce and co worked on a project where they drew a burn down chart showing the code base shrink from 1 million lines to two hundred thousand over a period of months.

I like Yves point. We may want to hide the features that are not used but we probably do not want to delete them. Just keep them as options.

Otherwise we might start removing the seat belts, air-bags and fire extinguishers from our cars.

chrismo

Perhaps a better analogy for the code with lean manufacturing is that code is design of the assembly line - the binaries compiled from the code are the assembly line machines. You have inventory in terms of what is required to deal with the assembly line itself (requirements), then you may have inventory that's input and output from the assembly line (data).

Seb Rose

Maybe, in the limit, there's competitive advantage to having no code ;-/

I'm off to plant some beans!

Bob Lauer

The reason why lean folks call requirements a liability is that they probably assume that - ideally - there is a direct 1:1 correspondence between a requirement (aka feature) and a piece of code. Which is really an ideal we should seek, but alas, we rather "encrypt" requirements in source code, as Charles Simonyi put it.

Ronny stalker

There's a lot in this post that I disagree with (mainly the idea that more compact code is easier to understand).

I agree that organizations benefit from strategically deleting code. This leads on to a more important point.... 'designing your code to be easily deleted'. Which often means avoiding writing 'magic' abstract stuff in favour of explicit concrete code. This might lead to more lines of code, but its code that can be easily traced and deleted.

iPhone contacts backup

become a code man.

The comments to this entry are closed.