Our class recently had the good luck of having a really good developer come speak to us about web development. Chardy Wang is the CTO of Stacck, a local company building products for F&B teams. His talk was held together tightly through one thread: how to develop web apps.

It’s one of those talks that would have been excruciatingly boring to me just a few months ago. This time it was great. He spoke directly to the problems we were facing every day writing code for web applications, and really for the first time, I could relate to a technical person. Big step up for me personally.

One of the most poignant memories I have of his presentation was when he answered a question from one of our classmates. The question was, “What was it like when you were just starting to build Stacck (the product)? As in, what was the approach of your team?”

It’s a great question, because while we’re the engineers behind the actual product, and are inherently valuable because of it, it would be a mistake to rest on those credentials to get us through our careers. It’s not enough. To build a great product that people actually want to use, be it web-based or even software-based or not, we must dig deeper. We must ask and come up with an answer to this simple question:

“Who are we building this for?”

Chardy and his team, perhaps under his experienced leadership in building products used by actual people (the number doesn’t matter as much as the fact), had a counterintuitive approach. Well, it’s unorthodox to developers anyway. Their approach was to not code at all.

Rapid Prototyping for Software products

Most of us would by now have heard the term “rapid prototyping”, used to refer to the process of quickly iterating through physical product prototypes using 3D printing tech. But few of us think about software that way, not even developers.

I think it has something to do with the fact that software development is, in 2016, fast by virtue. Fast in the sense that if you already had the code at hand, deployment wouldn’t involve talking to manufacturers and suppliers and moving things around the factory floor… it would just happen within a day on Amazon Web Services. All of a sudden, everyone with the right URL can start using your product.

This expectation makes software developers miss an important point of rapid prototyping - the user. Since building a product is as simple as flipping open our laptop and writing code, the notion of not doing that and instead spending time on thinking about the user (which produces nothing tangible) feels like a waste of everybody’s time. “Let’s build a minimum viable product and then we’ll test it.”

Often times, I find that when a developer says “let’s build a product”, it’s not the same as when a business guy or UX designer says it. Developers mean build, as in build. Something functional must come out of it.

Most people in a hackathon, however, don’t think that way. What they’re really thinking is “let’s conceptualise a product.” The actual functioning product can come after we validate our assumptions about what our customer wants.

Ego is the enemy

Here’s a hard truth that we, developers, need to face up to. Developing a product without any coding just doesn’t feel like development at all to a software developer.

But that’s a weakness, not a strength. Why?

Because coding takes a disproportionate amount of time compared to every other part of the product creation process. If you’re not a developer, ask a developer. Even they will agree with you.

I remember what it’s like to not know the level of complexity involved in creating a piece of software. I was constantly perplexed by what the hell goes on in giant tech companies when the products from them don’t seem to be changing that much from a day to day point of view. Most days of the month, Facebook stays the same; the way I’m used to it. Occasionally a new feature like rich responses (whatever they call it internally) comes along that is palpable as a user. So how does that warrant the hiring of hundreds of developers?

I’m alluding to the obvious. Coding is hard. The process is complex and tedious. Tens of moving parts have to work together seamlessly. Then hundreds, maybe thousands have to work well enough with one another as the product scales. But even at the starting phase, creating actually-functional software takes at least 5 to 10 times the time needed to build a decent wireframe with something like InVision.

So Chardy and his team approached the start of their long careers at Stacck the smart way. They, the development team, built wireframes (mock ups) of the product without writing a single line of code, and they showed that to their customers (or whoever they thought were their customers at the time). They received invaluable feedback, refined their mock up, and went out to get more feedback.

Only after iterating through a few cycles of “customer interviews”, as they call it in the startup community, did they start hitting Terminal and doing git commits.

To me, that’s what rapid prototyping should be about, even for software creators. Build fast (with rapid mock-up prototyping), fail fast, then succeed. This way, when we finally write our first line of code, we can give it our all with confidence.

(Image: Jonathan Velasquez)