

The Cost of Features (2013) - dennisgorelik
http://geoff.greer.fm/2013/03/06/the-cost-of-features/

======
ggreer
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%20201...](http://geoff.greer.fm/photos/screenshots/Screen%20Shot%202014-11-10%20at%2023.53.14.png)

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

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

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

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

