Be lazy, build better systems

https://www.compile.com/blog/product/be-lazy-build-better-systems/

by gingerjoos • 12 years ago

40 13 12 years ago

aqeel• 12 years ago

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

gluczywo2• 12 years ago

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-vaillant2• 12 years ago

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.

innguest• 12 years ago

If your build process and deployment are forcing you to decomponentize something so you have to copy and paste it, I'd blame those processes instead of saying there's an inherent shortcoming in the idea of composing components.

curun1r• 12 years ago

The problem with DRY is that programmers learn that it's a good thing but don't learn when not to apply it. There are very good reasons to repeat yourself. The mantra I learned, which has served me quite well, is: Optimize for less state, less coupling, less complexity and less code...in that order.

I've learned to happily repeat code if it means making my programs/components more stateless, more decoupled or simpler to understand. There's nothing worse than trying to make sense of code where a programmer tried to shoehorn two similar but ultimately different concerns through the same code paths.

I'll also happily add complexity if it means reducing coupling and state and add coupling if it means being stateless. State is the ultimate enemy that makes code inflexible and buggy, especially when it's mutable state.

srcerer• 12 years ago

Curious where "Optimize for less state, less coupling, less complexity and less code...in that order." came from. Would like to read more from that source.

mason55• 12 years ago

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• 12 years ago

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• 12 years ago

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.

coldcode• 12 years ago

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.

Glyptodon• 12 years ago

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.

Be lazy, build better systems

Related Stories