6 ms·

The Antipattern of the MacGyver Programmer

36 points by issa 14y ago

indiecore 14y ago
>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.
- billswift 14y ago
  "Nothing is hard to the person who doesn't have to do it themselves." Old quote, I have no idea the original source.
heathlilley 14y ago
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.
unwind 14y ago
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 ...
- chimeracoder 14y ago
  And yet it makes it to the front page of HackerNews and sparks a discussion on the underlying point... clearly the time-pressed, duct-taped, MacGyver solution was ineffective!
j45 14y ago
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? :)
gpcz 14y ago
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.
- issa 14y ago
  The antipattern involved isn't the messy work. It's the management's idea that the most efficient way to work is to always do everything as quickly as possible.
brudgers 14y ago
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.
- j45 14y ago
  "A shipping minimum viable product held together with bailing wire isn't so bad - even if vaporware provides the ultimate ease of maintenance." Totally agree. In general, Good grief. This contrarianism is a little unproductive. If someone gets something done quick... oh, well, you're going to have to throw away the code. If someone builds it the a little longer way.. oh, you're not using a rapid enough technology. They don't mention how your code won't work in 3 years because it might not be backwards compatible. Be careful to take the opinions of those who aren't shipping anything regularly.
  - sukuriant 14y ago
    Isn't that EXACTLY what the article said? Can I do it? Yes. And if I have to, given time constraints, etc, I will; but would I rather do it the more compatible way? also yes.
    - j45 14y ago
      I didn't disagree with it. I was speaking more generally to the attitude of contrarians that we come across. Hope that clarifies things.
    - eswangren 14y ago
      Well who would disagree with that? It's common sense; no article required.
- j_baker 14y ago
  You make it sound as though the options are either to hold it together with bailing wire or never ship. I think the correct answer is somewhere in the middle: Polish it when possible, hack it when practical.
nmcfarl 14y ago
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.
- pyre 14y ago
  In a non-start-up environment, it's usually not about the business coming to a crashing halt, but that it's hard to quantify the savings that you will reap by fixing something the 'right way.' This means that upper management won't allocate resources or approve projects/budgets/etc.
greghinch 14y ago
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.
- issa 14y ago
  I'll have to do a follow up post to clarify, as this seems to be the common second reading of what I was trying to say. Programmers of all levels can do Macgyver Programming. I was trying to point out that it is a mistake for any programmer's boss to want all code written that way.
priestc 14y ago
Programming is really two jobs in one. Writing new code, and maintaining existing code are two completely different tasks. Its surprising to m that the two jobs aren't differentiated more. It's ort of like the difference between an aeronautical engineer, and an ircraft mechanic. The engineer's job is to design the airplane to be robust, safe, and quickly fixable. The engineer is not expected to whip together a new aircraft design in a few hours. He is expected to take his time and get it right. The mechanic's job is completely different. His job is to fix the plane when it breaks. His job is to do it right, but emphasis is on getting it done quickly. If all new code is written in a way that is akin to the aeronautical engineer, the act of extending and fixing the code is simple enough to not ever need MacGuyver coders to fix it.
dustingetz 14y ago
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.
tjstankus 14y ago
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.
timo614 14y ago
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.
MartinCron 14y ago
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.

36 points by issa 14y ago

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

billswift 14y ago
"Nothing is hard to the person who doesn't have to do it themselves." Old quote, I have no idea the original source.

heathlilley 14y ago

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.

unwind 14y ago

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

chimeracoder 14y ago
And yet it makes it to the front page of HackerNews and sparks a discussion on the underlying point... clearly the time-pressed, duct-taped, MacGyver solution was ineffective!

j45 14y ago

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

gpcz 14y ago

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.

issa 14y ago
The antipattern involved isn't the messy work. It's the management's idea that the most efficient way to work is to always do everything as quickly as possible.

brudgers 14y ago

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.

j45 14y ago
"A shipping minimum viable product held together with bailing wire isn't so bad - even if vaporware provides the ultimate ease of maintenance." Totally agree. In general, Good grief. This contrarianism is a little unproductive. If someone gets something done quick... oh, well, you're going to have to throw away the code. If someone builds it the a little longer way.. oh, you're not using a rapid enough technology. They don't mention how your code won't work in 3 years because it might not be backwards compatible. Be careful to take the opinions of those who aren't shipping anything regularly.
- sukuriant 14y ago
  Isn't that EXACTLY what the article said? Can I do it? Yes. And if I have to, given time constraints, etc, I will; but would I rather do it the more compatible way? also yes.
  - j45 14y ago
    I didn't disagree with it. I was speaking more generally to the attitude of contrarians that we come across. Hope that clarifies things.
  - eswangren 14y ago
    Well who would disagree with that? It's common sense; no article required.
j_baker 14y ago
You make it sound as though the options are either to hold it together with bailing wire or never ship. I think the correct answer is somewhere in the middle: Polish it when possible, hack it when practical.

nmcfarl 14y ago

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.

pyre 14y ago
In a non-start-up environment, it's usually not about the business coming to a crashing halt, but that it's hard to quantify the savings that you will reap by fixing something the 'right way.' This means that upper management won't allocate resources or approve projects/budgets/etc.

greghinch 14y ago

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.

issa 14y ago
I'll have to do a follow up post to clarify, as this seems to be the common second reading of what I was trying to say. Programmers of all levels can do Macgyver Programming. I was trying to point out that it is a mistake for any programmer's boss to want all code written that way.

priestc 14y ago

Programming is really two jobs in one. Writing new code, and maintaining existing code are two completely different tasks. Its surprising to m that the two jobs aren't differentiated more. It's ort of like the difference between an aeronautical engineer, and an ircraft mechanic. The engineer's job is to design the airplane to be robust, safe, and quickly fixable. The engineer is not expected to whip together a new aircraft design in a few hours. He is expected to take his time and get it right. The mechanic's job is completely different. His job is to fix the plane when it breaks. His job is to do it right, but emphasis is on getting it done quickly. If all new code is written in a way that is akin to the aeronautical engineer, the act of extending and fixing the code is simple enough to not ever need MacGuyver coders to fix it.

dustingetz 14y ago

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.

tjstankus 14y ago

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.

timo614 14y ago

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.

MartinCron 14y ago

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.