
Be lazy, build better systems - gingerjoos
https://www.compile.com/blog/product/be-lazy-build-better-systems/
======
mason55
At some point your configuration just becomes code in a domain specific
language. They talk about a new employee picking things up pretty quickly -
it's not because they used configuration instead of code, it's because they
have a sensible architecture.

If your "configuration" is powerful enough to do everything you need then it's
Turing-complete and is just "code" by another name. If it's not powerful
enough then you'll need to drop down into the code layer pretty frequently
anyway.

~~~
serve_yay
This notion gradually descended my team into hell back when I was on a project
using Spring.NET, which actually does have a Turing-complete config DSL. But
that wasn't the main problem, the main problem was how much configuration was
needed to do absolutely anything. Mountains of it.

Create a component, then tell the framework how to instantiate it, then tell
the framework to instantiate one and give it a name, then pass that name into
anything that needs one.... blech.

------
programminggeek
The bigger question is, what do you do with the time you save? Are you just
piling on more work?

The reasons you invent things to get rid of the crap work is so that you can
do the work you really want to do. In my experience, people replace one pile
of work with another and call it progress.

Only the rare few will automate the things they should, and truly live the
freedom they have.

------
Glyptodon
I think your post explains (perhaps unintentionally) why I've never really
come to like working with Ruby on Rails as much as I liked working with
Django. Or at least continue to feel less productive with it (despite liking
Ruby).

Somehow the right amount of configuration seems to save a lot of work as
compared to conventions that fall just short of actual need.

I think there's a trap, though, that leads to the 'convention over
configuration' one-size-fits-all road, and it's things that require loads of
annoying, hard to manage, poorly structured configuration. (Things, like, for
example, Apache, IMO.)

Though perhaps I'm just not good at determining when to write my own
generators and when not to, I've also had Rails applications where I wrote a
generic controller that covered a dozen-plus models and wondered why there
couldn't have just been a generic controller built in to begin with (it's not
like it'd preclude bumping things out of generic into their own controller if
necessary).

I kind of wonder, too, if the evolution towards things like Docker/CoreOS with
stuff like etcd from more traditional Linux distros and virtualization might
also be viewable as a trend from convention towards a 'right amount' of
configuration.

Just some off the cuff thoughts.

------
coldcode
Configuration over code is nice until there is so much configuration you need
code to understand it. Also, if the configuration ever is wrong debugging is
likely painful.

------
aqeel
Every one knows the importance of DRY but only few follows it genuinely. This
article is a good reminder.

~~~
gluczywo
On the other hand I learned not to be too dogmatic about DRY because it
becomes costly especially in distributed systems where additional dependencies
introduced for reusability sake complicate build process and deployment.
Sometimes it's better to copy&paste instead of coupling components.

~~~
loup-vaillant
The trade off is rarely "copy&paste vs coupling components". Typically, you
would factor out a _third_ component that the original 2 would use.

Two components are hardly coupled just because they happen to use the same
library.

~~~
gluczywo
Separating the library does not remove dependency because library version
change affects both primary components so the change requires coordination.
This is really fundamental in large systems and I was hit by it many times.

Copy & paste sounds bad but what it really says is: let's make that piece an
invariant and don't import the library if you only need one short function.

So I would say the trade off boils down to "simplicity vs flexibility"

~~~
loup-vaillant
> _library version change affects both primary components_

In my experience, it changes neither, because the interface of the library
just doesn't change. Of course it depends where you make the separation.
Basically, if the interface to your library is big, you either suck at API
design, or you traced the wrong boundary.

Now if you happen to only need a small fraction of a sizeable library, I can
only suspect the library itself fell prey to scope creep. If there's no way to
import what you need, and little more, that probably indicates a problem with
the library itself.

Even big libraries which by nature must make many different things can often
be separated into different components. Like the SDL for instance.

\---

Oh, and I was assuming we were talking about _internal_ dependencies. Like,
_you_ write the library which will then be used in different parts of your
(possibly big) project. That's very different from external dependencies,
which are generally bigger, harder to freeze _and_ harder to update.

