sarahmei/gist:3650927

## gistfile1.txt
The Insufficiency of Good Design

We all want to write good code, and there is no shortage of advice on
how to do that. SOLID. SOA. SRP. LoD. These are undoubtedly important,
but none of them address the single factor that has the biggest impact
on the quality of a codebase.

That factor is Other People. The people you're working with affect the
codebase more than you do, in aggregate, if there's more than a few of
them. And it's not just the individuals. How your team is organized,
how it's managed, and how it communicates all leave unmistakeable
fingerprints on the code. Over time, a codebase grows to resemble its
creators, reflecting the good and the ugly of the individuals, as well
as the good and the ugly of their relationships.

This is not always a disaster. But it means that a team of really
smart individuals can, together, end up writing terrible code. And it
means that a lot of issues that get labeled "software design problems"
can't be solved by merely applying the right software design
principle. A team struggles with a problem like this for months, and
then a small, often-inadvertent adjustment to the team dynamics makes
the problem suddenly tractable.

I'll show you some common "design" problems in Rails applications that
actually stem directly from the topology of a dysfunctional team.
I'll talk about what you can do to solve them, and I'll give you some
tools for distinguishing between those types of issues and plain old
lousy programming. You'll gain a new appreciation for the invisible
forces that guide our design decisions day-to-day.
	The Insufficiency of Good Design

	We all want to write good code, and there is no shortage of advice on
	how to do that. SOLID. SOA. SRP. LoD. These are undoubtedly important,
	but none of them address the single factor that has the biggest impact
	on the quality of a codebase.

	That factor is Other People. The people you're working with affect the
	codebase more than you do, in aggregate, if there's more than a few of
	them. And it's not just the individuals. How your team is organized,
	how it's managed, and how it communicates all leave unmistakeable
	fingerprints on the code. Over time, a codebase grows to resemble its
	creators, reflecting the good and the ugly of the individuals, as well
	as the good and the ugly of their relationships.

	This is not always a disaster. But it means that a team of really
	smart individuals can, together, end up writing terrible code. And it
	means that a lot of issues that get labeled "software design problems"
	can't be solved by merely applying the right software design
	principle. A team struggles with a problem like this for months, and
	then a small, often-inadvertent adjustment to the team dynamics makes
	the problem suddenly tractable.

	I'll show you some common "design" problems in Rails applications that
	actually stem directly from the topology of a dysfunctional team.
	I'll talk about what you can do to solve them, and I'll give you some
	tools for distinguishing between those types of issues and plain old
	lousy programming. You'll gain a new appreciation for the invisible
	forces that guide our design decisions day-to-day.