
The Carrying-Cost of Code: Taking Lean Seriously - baha_man
http://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the-carrying-cost-of-code-taking-lean-seriously.html
======
famousactress
Deleting code is the single most satisfying action I get to take part in as a
developer. The thing is, I can get pretty happy about writing a graceful
function.. but all code is liability, and test cases. There's no act in
software development more elegantly productive that deleting code you don't
need.

Almost got me in trouble once, true story. I had a VP who asked another senior
dev type to round up LOC stats in our product for the past month (typical
ridiculous bullshit). The dev dutifully whipped together a tool that was the
equivalent of counting LOC changes from SVN commits. Deleted lines counted
negatively :)

Even though I was the most senior coder on the team, and at the time certainly
impacting the most change in the source tree, I was riding somewhere close to
zero according to his tool and had some 'splaining to do.

Most large software projects that I've been a part of hit a phase somewhere
between year two and three where I think they deserve a net code loss for
quite a while. There's just so much well-intentioned bullshit that gets piled
on in the first year or two of a project, and often doesn't get re-evaluated..
or someone on the team is operating under the delusional belief that someday
that code will serve the project well in it's current, half-assed, un-tested
form.

------
jacabado
For this to take place we need better IDE's, ones that gives you more context
on the code:

* when it was written, by whom and to answer which need

* when was it changed and to solve which issue

* if it has been ever debugged and if any bugs where ever found inside it

When I'm chasing some nasty bug in my code and I refuse to accept it was some
recent change it's incredible that 90% of the times I bang my head against the
wall with some bug in a recently changed bit of code. If just my IDE could
highlight the code from the last 3 commits of me and my coworkers it would
ease my life so much.

~~~
DougBTX
You can use svn blame in Eclipse to do some of this.

Instructions: [http://stackoverflow.com/questions/223657/svn-blame-in-
eclip...](http://stackoverflow.com/questions/223657/svn-blame-in-eclipse)

Screenshot:
[http://wiki.c2b2.columbia.edu/informatics/index.php/Eclipse#...](http://wiki.c2b2.columbia.edu/informatics/index.php/Eclipse#Show_Annotations_.28Who_Modified_the_Line.29)

This will allow you to see commit messages in the code editor on a line-by-
line basis. To know if a line of code had a bug in it, you would need to make
sure that that sort of information is written into commit messages. Here we
use a "Fixes issue #12312" trigger in post commit hook, so that the commit,
the code change and the Trac ticket are all linked.

~~~
jacabado
I also use it (from Visual Studio), but I can't edit while in the "blame"
view, it's something outside VS, I guess the Ankh plugin is responsible for
that.

What I need is something in the code when I'm editing it, it could be some
kind of hint how "old" is the line and if I mouseover it would give me the
blame information.

I will check if I can build some plugin for VS or if somebody has done it.

------
sunir
One of my favorite interview questions for software developers is "how many
lines of code have you deleted in one day?"

The question helps assess their maturity. It throws some people who think
software is about adding continuously. Senior people know what I mean usually.

No code has no bugs. And _no-code_ has no bugs.

~~~
patrickyeon
It's a story we've probably all heard many times before, but I give you a
story from the old Apple days: -2000 lines of code
[http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...](http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

~~~
arethuza
People often talk about technical debt, but arguably what projects need is an
entire balance sheet of assets and liabilities. I don't mean this literally,
but just having the idea of debt doesn't quite sum up the possible state of a
project in the same way that a balance sheet sums up the financial state of a
company.

~~~
thwarted
Technical debt can be roughly calculated from the number of open tickets that
say something should be revisited and the number of times TODO and FIXME
appear in the source code. Of course, if you don't ticket things that need to
be revisited or write those comments, you have incalculable technical debt,
which is even worse.

------
mberning
This is great from an engineering standpoint, but I would really like to meet
a sales guy that would be willing to support this. It's very hard to tell a
potential customer, in a nicer way of course, "We don't currently do X, Y, and
Z, and we have no future plans to". Sales opportunities are where many of the
ill conceived and infrequently used features in a product come from.

~~~
quanticle
Apple seems to get away with it all the time. For example, look at Steve Jobs'
keynote where he presented Snow Leopard. He turned '0 New Features' into a
selling point.

~~~
mberning
They do to an extent. The original iPhone lacked many 'non-essential' features
that were later added.

------
hxa7241
Instead of talking of 'carrying' code -- Dijkstra frowned on that kind of
metaphorical thinking (sensibly so) -- it might be clearer to rephrase and
summarise this in more straightforward terms.

The problem here is that larger code is more complex, and more complex is
harder to work on. The suggestion is that we impose limits on the amount of
code. That seems somewhat prudent, but it does not really attack the problem:
we want to make code easier to change _despite_ it being more complex.

Just limiting code size is not really a solution. Very broadly, functionality
is proportional to code size (in general, and in particular where all else
stays constant -- is that not reasonable?). So limiting code size is limiting
functionality -- which is setting limits on what we do. We do not want that,
we want to make things easier.

Also, this limiting really amounts to re-arranging the costs. It is
transferring the costs of future change into costs of current activity. But
instead of paying those moved costs by doing _more work_ now, they are paid by
having _less functionality_ now. Is that not contradictory to one of the
principles of agile (or at least XP)? You do not try to predict the future,
you just do only what you need now.

~~~
rick_bc
I think "carrying-cost" is ok. Perhaps not for newbies, but for seasoned
developers it's clear what this is about without translations.

------
timclark
Nice insights on the inventory analogy in software.

