sarahmei · September 6, 2012 03:43 · billgathen · Sep 6, 2012
diff --git a/gistfile1.txt b/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.