The Carrying-Cost of Code: Taking Lean Seriously | Hacker News Reader

The Carrying-Cost of Code: Taking Lean Seriously

michaelfeathers.typepad.com

62 pointsbaha_man23 comments

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.

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.

Emacs [1] can do the "whom, when" part.

The "why, what issue, what bugs" part might be addressable by literate programming. But not a lot of people try that.

[1] Or most decent editors in cooperation with your version control.

If your SCCS check-ins reference issues, an IDE ought to be able to address "what bugs" through "which issues."

Agreed, IDEs could do a lot better still on the 'social' aspect.

My first thought on reading this was that you don't use version control, but then I see you mentioned commits. Seems there are several IDEs and VCS that play nice together, SVN support seems relatively common. Maybe not automatically showing the last three revisions, but it isn't much effort to do a diff across revisions, or see who touched each line last on the current revision.

I just want it there every time as a small unobtrusive clue.

How many times is that feature used vs how many times could it be useful? (or the others suggested here who need user intervention and never allow you to code while seeing this info)

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

Instructions: http://stackoverflow.com/questions/223657/svn-blame-in-eclip...

Screenshot: http://wiki.c2b2.columbia.edu/informatics/index.php/Eclipse#...

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.

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.

Visual Studio also have an "annotate" option, which shown in the margin for each set of lines who wrote the code, when, and the commit message.

Back in my Cobol/CICS days, every line that was edited was marked with a 3-character identifier for the person responsible. In a limited "ide" this made it possible to find the person responsible and at least ask him/her for more information/documentation.

I use a similar idea which is very low-tech, but use the date for each line/function that is changed, like this:

v110117 Statusbar.Text (string, in::statusbar_type_info);

v110117 is simply a macro where I explain the high-level rationale/bug/functionality (which is visible on mouseover-tooltip). If you need to edit different functions to fix a bug, it is a simple search for v110117 to find all changes (the comment at the end of the line may be marked v110117a, v110117b etc to separate different issues, and the detailed explanation for the changes done in that line/function is explained there).

You will quickly see if there has been any changes in a function lately due to the date-format (vYYMMDD). A bonus is that if a function has many different changes it is immediately visible, and should be a warning that the function is complex/high maintenance.

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.

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...

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.

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.

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.

That's typical in companies that are seeking market. Afterward, you're more likely to have a product manager calling the shots, and they often decide against features for various reasons.

The fact of the matter is that companies can make these sorts of choices. It may be hard, but it isn't impossible.

Precisely. When you NEED that next sale to stay alive it is near impossible to justify saying 'No' to the potential customer.

In my experience though, once you make it a habit of adding features to placate prospects, it is a very hard habit to shake.

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.

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

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.

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

Nice insights on the inventory analogy in software.

Reply on news.ycombinator.com