The Antipattern of the MacGyver Programmer

I think there is some kind of irony here stemming from the fact that the author posted this, probably to get it done (because he could), before taking time to e.g. fact-check how to spell MacGyver ...

Kludges are not necessarily an anti-pattern. Time is a constraint.

MacGyver put eggs in the Jeep's radiator because it had bullet holes, and the drug lord's minions had a helicopter.

A shipping minimum viable product held together with bailing wire isn't so bad - even if vaporware provides the ultimate ease of maintenance.

I don't believe MacGyver vs. Careful Designer is a strict dichotomy of anti-pattern vs. pattern. Instead, they are both valuable approaches when used with proper judgment at the right times. For example, the MacGyver approach is appropriate when making a proof of concept or prototype. Once the project goes from breadboard to a real device, you use more Careful Designer patterns.

If you're doing messy work, lay out a tarp rather than labeling all messy work as an anti-pattern.

Clearly from the comments there are a lot of reasons for this but I'm going to throw out another that I have some experience with: "living to eat another day"

Sometimes there just isn't any runway, and loosing this deal, customer, etc, really isn't tenable for the company. Features need to be live today.

Did this suck for future me? Yes it did, and to some degree does still. But was it the right business decision? Absolutely.

IMHO this the "Get's things done." part of the developer skill set defined by Joel Spolsky. A wizard at solving problems without an eye on maintainability or the long term picture.

The antithesis of this is the "Smart" guy who can design the "perfect system" upto and past the release date.

Personally I don't get the argument that you can either have speed or well architected systems.

Yes, if you build features outside the scope of the system to meet unforeseen features it's just scope creep and a waste of time but if you take a few minutes to actually think before you code the actual implementation time is usually on par (assuming you're not working in system that has allowed bad programming practices to take place; isn't DRY, etc.).

I've worked with people that copy and pasted half of their code base on a few occasions. Whenever a change needed to be made to a few of the more complicated systems you had to give it to the original 'rockstar' developer because he was the only one who knew every location it was used in the system.

To me it's just a sign of laziness. The effort to introduce design patterns and keep your code DRY is trivial. Just keep scope in mind and don't build systems to anticipate unforeseen features.

I do get the whole MVP we need to get it out the door argument but usually if you hire people who know what they're doing and aren't just an inflated ego (we all know those sorts of developers) it's really not a problem because they'll take the few minutes to think before they implement.

I have met experienced programmers that keep code simple enough, and be kind to their future selves when things need to be developed.

Often with inexperienced developers they go through the extremes of overly complicating a solution, or overly simplifying it.

The middle way, I'd say is more architecting enough of the inner workings of the system, and only building out the bare essentials of it, leaving room to grow.

Is this post relevant to MVP's? :)

The problem isn't necessarily the MacGyver hacks. It's building stuff on top of them that hurts. If you realize you're making a MacGyver hack, the responsible thing to do is refactor when it causes you pain. If that time is never, congrats, you got away with it. But hacks on top of hacks, in the interest of some management constraint is, in my experience, a recipe for failure.

posts like this do not even begin to cover the intricacies and scale of large development projects with make-it-or-break-it business timelines. we're not all building apps.

The distinction I like to make is between firefighters and fire marshals. It's not that one is "better" than the other in any general sense.

When your house is on fire, you want the guy with the hoses and axes. To keep the house from catching on fire in the first place, you want the fire marshal to tell you that your kerosene collection might not be a good idea so close to your wood stove.

My experience is the MacGyver programmer equates to an inexperienced/unguided (as in no effort to learn how to learn to design code, through school or other means) person, often young and/or arrogant. If something is worth doing it's worth doing right. If you're creating something of worth, you're going to have to revisit any code you write for changes/updates. The MacGyver programmer has no place on any of my teams. Not only do they often create more work than they accomplish, they poison the morale of the rest of the team who have to pick up the slack and clean up after them.

>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?

The problem is often that whoever is calling the shots isn't a programmer themselves. I often run into the problem of something that LOOKS simple on the outside but is actually really complex being asked for with a "well I mean it can't be that hard" and explaining why it's actually hard to do and integrate would require explaining a whole pile of stuff that would definitely cause glaze-over.

This is why I find working with a technical person and keeping the marketing/business types far far away until I'M satisfied with the thing I've built to be much less rage inducing.