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 ...
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!
"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.
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.
<It's not my analogy> MacGyver either puts eggs in the Jeep's radiator or dies at the hands of the drug lord's minions. Manny's Garage will have it for you next Tuesday isn't an option. </It's not my analogy>
If you have a small leak in your radiator, you can use black pepper to patch the holes. Use about 2-3 slightly heaping teaspoons and put it in the radiator cap (not the reservoir).
It works because black pepper will not burn at those temps in radiator fluid. When the pressure and heat squirt out small amounts of fluid, a grain or few get stuck and patch the hole temporarily. 2 spoons will solve your problems for a few months.
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.
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.
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.
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.
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.
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.
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.
>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.
