The Cost of Features (2013)

I didn't expect to see this on the front page of HN, but I guess I should provide an update.

Looking back, I agree that the car/plane analogy was stretched, but I still stand by this advice. Too often, I see code bloat that simply isn't worthwhile, and I constantly work to correct the problem. Today, we removed backbone.js from our front-end code. The change improved load times and reduced complexity. I'm quite happy with it. It only took a few days, but it will pay dividends indefinitely.

In terms of day-to-day activities, I'm still busy with work[1] and I've continued the same GitHub streak[2]. As blog posts go, this one hasn't caused me much embarrassment.

1. https://floobits.com/

2. http://geoff.greer.fm/photos/screenshots/Screen%20Shot%20201...

This reminds me of a post by Michael Feathers, titled "The carrying cost of code" [1]. Feathers wrote the book about legacy code [2]. I think he makes approximately the same point:

> If you are making cars or widgets, you make them one by one. They proceed through the manufacturing process and you can gain very real efficiencies by paying attention to how the pieces go through the process. Lean Software Development has chosen to see tasks as pieces. We carry them through a process and end up with completed products on the other side.

> It's a nice view of the world, but it is a bit of a lie. 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.

[1] - http://michaelfeathers.typepad.com/michael_feathers_blog/201... [2] - http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...

I'd guess financing and marketing generally, and lease cycles in the US specifically, are the main drivers (pun intended) for the pattern in cars. The analogy sounds nice but it is a little stretched trying to explain codebase size in OSS projects.

The reason why cars are much heavier today is because they are made much safer than in 1975. All those crumple zones are heavy, and to be safe you don't want to drive the lighter car in the collision.

> Do people use modern languages, libraries, and techniques to build a small piece of software that does one thing well? This is the Unix philosophy, but when I try to think of examples, not much comes to mind.

Exaclty! Why? Is it hubris or what that building single-purpose components is such an anathema nowadays?

The reason why cars gain weight so much is that they now grow up with the buyer.

eg. Instead of moving from the civic, to the accord, you now stick with the civic through your lifetime, or at least that the theory according to new trends in automotive marketing.