Hacking Vs Engineering: Not All "Bad Code" is Bad

[kyle_vermeulen]

Originally published at: http://www.sitepoint.com/hacking-vs-engineering/
A few days ago, I had a conversation with a colleague that changed the way I approach new projects.

Michael De Wildt is the former Senior Engineer at 99designs, and helped scale their infrastructure during their massive growth. He also built a successful WordPress plugin “WordPress Backup to Dropbox” with 1M+ downloads, and co-founded a company called Influx.com that provides customer service as a service.

Thanks to his experience on both the engineering and business side, he brings some pretty rare insight to conversations about software development. Our main focus was around when to engineer something, versus when to hack together a prototype.

Hacking versus Engineering

Here’s my Product Manager Confession: Despite all the user stories, research, and testing, it’s almost impossible know if you’re building the right thing… until people use it. That’s ok. It’s honest. It’s silly to pretend the scope is often more than a good guess at a potential solution. Getting users in as early as possible is key.

Mikey’s approach—hack first, engineer later—is really refreshing. It allows for a better understanding of the process and requirements. “This is a prototype, it’s ok if it breaks” vs “This is a business requirement, and a feature we’re going to be supporting forever.”

The challenge becomes to build a culture of trust that assures that everyone on the team has an understanding of the constraints of each. When a hacked-together feature breaks, it’s expected.

Here are a few quotes that hit home:

Building vs Hacking (3:00)
“You don’t build a bridge across a river until you know it’s worth building to the other side. An engineer would come and build a bridge regardless. A hacker would get across the river first to ensure it’s ok. So a good software developer will take their rickety boat across the river and make sure it’s worth building the bridge.”

On Teamwork and Trust (3:56)
“In order for a developer to hack, they need to trust—their product leader or whoever is in charge of the direction of the business—they need to trust they will be allowed to turn it into a bridge after the hacking session. If that trust is broken, it’s going to be very difficult to get an engineer to hack again. Cause they’re like “Last time this happened, you just left this s***y structure, and didn’t let me turn it into a bridge. And now look at it.”

On Scaling (9:23)
“Over time, as a team get’s bigger, (hacking) gets harder to do. When you’ve got one person who knows that this part of the app is not very good … it’s pretty easy. When you get 5, 6, 7 developers, that’s when it gets hard to do.”

It’s worth noting that a process like this requires excellent communication and trust in a team. If there’s low trust and a culture of blame, this probably won’t work. As the Agile manifesto says: Individuals and interactions over processes and tools.

Would this process work for you? Or is hacking just something that happens at startups and side projects? I’d love to hear what you think.
Continue reading this article on SitePoint

[damijanc]

I find it surprising that we still have this revelation. In the “old days” we used to make a prototype or proof of concept first and then build the solution based on the experience. Now this is seen as a waste of time since speed is the most important asset and technology does not matter . This leads to over-engineering or future proofing of the solution , brainless usage of frameworks and patterns or too early adoption of new technology. All because you will not be allowed to throw anything that is “working” and you will be maintaining it forever.

[rpodsada]

Recently I dove head-first into robotics, specifically looking at building a 3D printer or CNC machine. Yesterday I read an article about backlash which had an interesting insight about “Engineering” vs. “Hacking” from a engineer’s standpoint, and whether an inaccurate build is actually “bad.” The insight in the article was that hacking is engineering, just engineering to much larger tolerances. In mechanics, tolerance is a measure of effectively how “off” something can be. E.g. a length of pipe must be within +/- 0.01 inches of its intended length to do the job. Just like a web application must do X, Y, and Z to do its job. In the case of a rough prototype, the pipe might work fine as long as it’s within 1" of the intended length. Or in the case of a web app, maybe 50% of feature X, Y, and Z is enough to demonstrate the concept. As long as the tolerances meet the intended purpose, the engineering is sound. Was an interesting way to look at this and whether “hacking” is bad or not. Effectively, there is no such thing as hacking (although, there IS such a thing as just plain bad code…)

[kyle_vermeulen]

Very interesting. That’s a really good way to put it. So with prototyping, there’s a ton of tolerance on most parts of a product, and a team can verbalise that, whereas with engineering there’s often very little tolerance or room for error.

Helpful (and cool!) to see these same concepts applied to physical manufacturing, and see that they’re not new ideas