4 ms·

The Cost of Features (2013)

38 points by dennisgorelik 12y ago

ggreer 12y ago
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/ https://floobits.com/ 2. http://geoff.greer.fm/photos/screenshots/Screen%20Shot%202014-11-10%20at%2023.53.14.png http://geoff.greer.fm/photos/screenshots/Screen%20Shot%20201...
shoo 12y ago
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/2011/05/the-carrying-cost-of-code-taking-lean-seriously.html http://michaelfeathers.typepad.com/michael_feathers_blog/201... [2] - http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...
rumcajz 12y ago
> 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?
- fleitz 12y ago
  It's the environment, code completion leads to more code. Big frameworks lead to big apps. Also, if you string together exactly what is needed in a few hours with bash, pipes, and unix command line tools you'll be called a hack, cowboy coder, and everyone will be asking where the DI framework fits into whatever would have taken them 2-4 weeks to produce.
fleitz 12y ago
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.
Ma8ee 12y ago
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.
ronilan 12y ago
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.

38 points by dennisgorelik 12y ago

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/ https://floobits.com/ 2. http://geoff.greer.fm/photos/screenshots/Screen%20Shot%202014-11-10%20at%2023.53.14.png http://geoff.greer.fm/photos/screenshots/Screen%20Shot%20201...

shoo 12y ago

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/2011/05/the-carrying-cost-of-code-taking-lean-seriously.html http://michaelfeathers.typepad.com/michael_feathers_blog/201... [2] - http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...

rumcajz 12y ago

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

fleitz 12y ago
It's the environment, code completion leads to more code. Big frameworks lead to big apps. Also, if you string together exactly what is needed in a few hours with bash, pipes, and unix command line tools you'll be called a hack, cowboy coder, and everyone will be asking where the DI framework fits into whatever would have taken them 2-4 weeks to produce.

fleitz 12y ago

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.

Ma8ee 12y ago

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.

ronilan 12y ago

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.