The Antipattern of the MacGyver Programmer

MacGuyver is amazing. He can take a ball of string, some paperclips, and a piece of chewing gum and build a functional airplane. But the point that is often lost is that he’d much rather build an airplane out of airplane parts.

Being a MacGuyver Programmer is great. When you need to, you can throw together working code out of whatever is available. But just because you CAN code that way, doesn’t mean you SHOULD.

A (relatively) small amount of extra time and effort means writing code that is more organized, commented, efficient and extendable. One of the hardest day-to-day jobs of programming is convincing others that the additional time is worth it in the long run.  Can I tack on an additional feature in a couple of hours? Yes. Will that mean time lost down the road when that feature isn’t properly integrated with the rest of the code? Yes. Sound familiar?

This entry was posted in Programming. Bookmark the permalink.

12 Responses to The Antipattern of the MacGyver Programmer

  1. brunnsbe says:

    I think you mean MacGyver and not MacGuyver…

    • admin says:

      I do! sheesh….you’d think I didn’t grow up watching that show. I’ll quickly change the title and build a redirect out of my shoelace.

  2. Well now, MacGyver’s inventions worked perfectly given their constraints and their use cases….and I would argue that that type of coding is perfectly justified if what you need is a quick one time only piece of code. Too many people get caught up in over engineering single use apps which just wastes time. Horses for courses.

  3. Vance says:

    I think he meant MacGruber and not MacGuyver…

  4. Todd says:

    I think he meant McBain and not MacGruber…

  5. Anon says:

    I like cheese!

  6. Paul says:

    Actually, what sounds more familiar is the metric tons of code I’ve seen lovingly commented and meticulously future proofed that never saw the light of day again. Presence of comments is not a quality metric. In fact, I think comments decrease maintainability a little bit.

    Give me a couple of MacGruber coders any day.

  7. Just be very careful when trying to make new code organized and extendable. The organization of the final solution may not be clear at the start and the ability to later extend it may never be needed and add unwarranted complexities.

    Never build the bridge before you get to the river.

  8. Florian says:

    Every approach, methodology, flavor and philosophy of writing code has its proper place. Even the seemingly abhorrent. The difficulty isn’t applying one or another of them blindly. The difficulty is knowing when to approach a problem how.

    Without harking back too much into the up-front vs. late design debate. Both have pitfalls that will get you if you don’t know what their respective strengths are.

    If you spend a lot of time engineering every solution up front, you run a risk of over-engineering things you will never need, which in fact may become infrastructure dead weights, i.e. negative work.

    If you jump into everything with little planing and forethought you run a risk of piling up technical debt in things you didn’t solve properly, and unless you repay it, it’ll keep charging interest.

    Generally I’d think you should err on the side of the MacGyver methodology. The future (i.e. requirements) are unknowable before you started doing something, whereas you can limit the impact of technical debt you pile up (refactoring) but it’s extremely difficult to recover negative time from the past.

    • admin says:

      Florian, I agree completely. The point is that sometimes you need to work by the seat of your pants, but sometimes you can do better!

  9. pjz says:

    Better than building it is finding a complete solution that someone else has already written. Don’t reinvent the wheel! There are more than enough ORMs and templating languages and commandline parsers in the world… among which is one that’s well maintained and has already fixed all the bugs you’re about to write into yours.

  10. Matt D says:

    good tailors leave just enough fabric at critical positions to allow the garment to be “taken out”, or even “taken in” without changing its overall shape. they don’t leave meters of fabric at each seam. leaving just enough, in the right place.

    good programmers do the same thing.

    macgyver programming is like buying a tshirt from kmart, sure it might be functional, for a while, but it’ll need replacing before too long. and if someone happens to pull the wrong thread…

    so dear programmers, are you a master tailor? or someone who works in a sweatshop banging out cheap tshirts?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>