
The Antipattern of the MacGyver Programmer - issa
http://livelongandprogram.com/2012/08/13/the-antipattern-of-the-macguyver-programmer/
======
unwind
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
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!

------
brudgers
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
"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
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
I didn't disagree with it.

I was speaking more generally to the attitude of contrarians that we come
across. Hope that clarifies things.

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

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

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

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

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

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

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

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

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

------
indiecore
>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
"Nothing is hard to the person who doesn't have to do it themselves." Old
quote, I have no idea the original source.

