The easy way, the hard way and the fast way

Between my personal projects and those at my daytime gig, I've had a lot of discussions lately about how to write code. You can do things the easy way, the hard way and the fast way.The

reason I think about this is because I'm one who frequently gets so wrapped up in detail that I often fail to actually deliver something functional quickly. There are pros and cons to all of these ways, and sometimes they overlap. In an ideal world, we want everything to be easy and fast.

Easy means you can roll with something that already exists, or mostly exists. You find that magic class, and you bang out what you need. The downside of this is that you may be compromising flexibility elegance.

Hard means learning new things, applying a design pattern you don't fully get or working through some refactoring that spawns a million classes. The benefit is that you end up with something flexible, clever and reusable.

Fast means the path of least resistance, even if it means hacking out some functionality you already have somewhere. It's like concatenating a string because you don't know about, or don't understand, String.Format(). If other people are going to consume or molest your code, this isn't an option.

I know what you're thinking... duh, you need to combine all of those elements. I believe that's true. But as is the case with many things abstract and emotional, sometimes it's hard to reconcile it all into actionable standards.