A few days ago, I had a conversation with a colleague that changed the way I approach new projects.
Michael De Wildt is a 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.
[youtube WZmG5aWpdBc]
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 (0:32)
“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 gets 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.
Kyle Vermeulen
