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.

1 Comment

  • I must admint, I feel that is a good way of putting it.

    What happens to me all to often is I "get so wrapped up in detail" and a strive for quality/ scalability.

    During the life cycle the "Hard also comes into play as well due to ignorance and attempting to keep up with you all.

    As the clock continues to tick, the "Easy" aspect comes into play while attempting to met deadlines.

    What happens in the end is a roll of the dice, really depending on scope, IMO. Sometimes it all falls into place, but for me, I don't think I have ever implemented a project that 2 months down the road I am displeased with where it landed (code wise). Stakeholders are content, so that's good, but I have never been completely satisfied with the code.

    Still haven't had my sistine chapel. Someday...

    BTW - Never, under any circumstance believe a manager of stakeholder who says, we will give you time to "clean things up" once we rollout, "lets just get it done..." It never happens, or at least, that bargin has never been upheld for me...


Comments have been disabled for this content.