26 Apr

There is no right way

I get this question a lot when talking about a particular technology or pattern: “What is the right way?”  I get this with an expectation that there is always one solution that is the correct answer.  Are we all studying for a test?  There is no RIGHT WAY.  There is no “One True Solution”.  There is no “This will be correct for all time”.  Please get over it.

There are right ways (notice the plural), there are better ways (notice the plural), and there are bad ways (of course this is plural, you all no that).  If you want further examples of this at work, just look at the recent set of posts between Greg Young and Ayende on how to make a repository.






I think I got those in order.  Here is the deal: they are both right for their particular situation.  Both have very good reasons for doing things the way they are, and both are probably correct for what they were doing.  Greg is actually very good at saying things like “yes, this is a good pattern, but please don’t use it in that context” (that quote is an out of context paraphrase). 

This isn’t just about design patterns or algorithms btw.  This applies to just about everything you do.  Technology stacks, design, architecture, , project management, planning, scrum, childcare, and lawn care.  If you have multiple kids, you know that every kid is different, requiring different approaches and handling.  One takes a timeout, the other needs their allowance docked.  Same goes for your code.  What is correct in one situation may not be best in the next.  Development requires nuance and wisdom.

So what do we have for you?  A long list of things not to do.  Stuff like: don’t use DataSets, ViewState can be evil, GOTO causes your brain to rot, and don’t have 500 lines of Ado.Net code inside of button clicks to update your view. Read TheDailyWTF for more.  What we have now are a long series things that are better than that.  Unit Testing is good, BDD is better, Agile is better than Waterfall, layers will help make code manageable, ORMs are better than raw SQL and Ado.Net.  But all of those are just better.  They are still not ultimate truth by a long shot.

So instead of asking “What is the right way?”, take a step back and ask, “Is there a better way?”  There probably is.

9 thoughts on “There is no right way

  1. I think even with your caveats, your last paragraph but one is treading dangerous ground …

    None of the things you list are definitively better than the thing you preceeded them with, in many cases they are worse significantly … you didn’t apply your own rules and put any context. With context I can state that SQL strings are better than any ORM, and that waterfall is better than Agile. Even with very little context I can justify that TDD is better than BDD.

    Context is significant, as is experience of the alternatives.

  2. The context of your problem is a key consideration whenever making a decision on an aspect of your application and being able to identify what is the better option in a given situation can really make or break a project.

    I’ve spoken to many people who stick to the tools they know and never considered that something else might be a better fit and end up paying a price later on.

  3. Hey Chris, found your site via PostSharp.org, so far I like it a lot.. I’m big on elegant code.. nice domain =)

    I am happy to see this blog because it reinforces one of my core coding philosophies… finding “the least bad idea.”


  4. (immediately after posting, went to the homepage and noticed that is a multiperson blog, and so I hereby redirect the first statement to whoever runs this)

    AnnotatePost( postBuffer[ currentIndex – 1 ], “Oops” );

  5. Thank you!

    This notion is also nicely complemented with the Rule of Three that Johanna Rothman talks about:

    If you can’t think of at least 3 possible solutions, then you don’t understand the problem.

Comments are closed.