Instantly share code, notes, and snippets.

Embed
What would you like to do?
The Insufficiency of Good Design
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.
@sarahmei

This comment has been minimized.

Copy link
Owner Author

sarahmei commented Sep 6, 2012

This is a talk I'll be doing at RubyConf in November. Somewhat incomprehensibly there are still tickets left: https://rubyconf2012.busyconf.com/bookings/new

@billgathen

This comment has been minimized.

Copy link

billgathen commented Sep 6, 2012

Excellent perspective. I believe this happens on single-developer projects as well, since we all deal with ignorance of our own ignorance, unconscious biases and lack of oversight/accountability. I like to say "a different perspective is worth 50 IQ points" but when you're flying solo, you're always the smartest (and dumbest) person in the room. Looking forward to hearing it in person!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment