Check out a free preview of the full Rapid Application Development with Code Generation course:
The "Prototyping Q&A" Lesson is part of the full, Rapid Application Development with Code Generation course featured in this preview video. Here's what you'd learn in this lesson:

Lukas answers student questions regarding if call and apply will be covered, how to lead a conversation regarding throwing away versus productizing a prototype, and what metrics can be used to validate trying a new idea.

Get Unlimited Access Now

Transcript from the "Prototyping Q&A" Lesson

>> Yeah, so, just a quick comment came in about Feynman I believe we're talking about Richard Feynman who is I think, is set forth a blueprint for anybody who aspires to achieve mastery with any domain. He is phenomenal, I also recommend and ironically somebody said, you should learn how to draw basic diagrams, and I totally agree.

[00:00:25] Keynote is my favorite, and I've spent a lot of time drawing diagrams. This is a totally random comment, but Edward Tufte, is kinda one of the godfathers of informational representation and visualization, and I think that the stuff that he's done is absolutely fascinating. So, there was a question that came in on a few chats if I was going to talk about call and apply, and I have an example on if you look into the stack blitzes on event storming and there is a piece of code in there where I do use apply and I will comment on that when I get there.

[00:01:10] So, the question is in a business context, how do I lead the conversation when it comes to throwing away the prototype versus productizing it. And I would say one, the business case for building the right thing is airtight, that it does not take too much logic to make a case that we should build things that people want.

[00:01:45] And so, first of all, you have to establish that and a lot of times I've had to reduce what is a very emotional conversation into, are you telling me that you are willing to invest organizational resources to build something that our users may not care about? And so, most people are like, no, no way.

[00:02:12] That's what I'm saying. And so I said, when it behoove us to ensure that we are building the right thing. And so first of all, I believe a lot of times even conversation sometimes can get emotional when in fact the two people on each side of the table they want the same thing which is to build things that people love Is just becoming aligned on how that's going to look.

[00:02:36] And so that one, the conversation has to be like, are we committed to building something that people care about? Secondly, are we committed to doing it the right way? And on the flip side is engineers that I am going to, hopefully in this workshop, help you close that delta between this is prototype code, this is production code to where if I'm doing a high fidelity prototype, there's absolutely no reason why I couldn't launch it.

[00:03:14] Because I endeavor to write my prototypes to the same standards that I would write any other code, the reason why would throw it away is because it's immutable and I need a another iteration. And I think it would actually, it would be interesting for organizations that are I would say very rigid and stuck in their ways to start treating or adopting more of a prototype mindset in the sense of how do we iterate fast and push things out to our customer base.

[00:03:51] So, a company's ability to take an idea, and put it in front of a potential customer. That the time that it takes to do that, and a company's ability to shorten that is its greatest competitive advantage. So, one, the conversation is, at the end of the day, we're saving time and we're saving money.

[00:04:13] The next question that is how do we do that? And one of the mindsets around rapid prototyping that I want to address, is that prototypes are substandard that they should be thrown away, and the answers I believe when you do them correctly, they don't have to be thrown away.

[00:04:31] When you reach an iteration that you like, keep that iteration and it's comes down to just a slightly different approach to architecture. The question is, when you are reducing effort and I think time to build a prototype or an artifact. How do you measure that in a meaningful way?

[00:04:54] If that's, if I understand that correctly, is that when you are communicating, like, Hey, I want to try this, by what metrics can we use to validate that? And this is a little bit science, a little bit art, but I think ultimately organizations should, one, keep track of how long it takes for an idea from conception.

[00:05:22] So, the time from conception to production is really important. So, this is where you have to have a good relationship with the product team and as well as the architecture, the infrastructure teams, how long does it take for an idea to get put into production? And you need to keep track of that.

[00:05:44] Secondly, is you need to keep track of the things that we have in production. What is the engagement around these particular features? And so, one, if you built in, if you go read the lean startup and there's tons of books on this, that if you spent six months building something, and it should have taken 12 months, but you did it in six months and nobody uses it, was that a victory?

[00:06:15] Did you actually accomplish anything? And the answer's no. And so, ultimately, at the end of the day, we as programmers, we exist to build things that are meaningful and have an impact and are relevant to people. This is why program, I don't think about languages, I don't think about frameworks.

[00:06:35] What I think about is, can I put something in somebody's hands that's going to make their life better? Am I going to reduce pain? Am I going to help them do something faster? Even am I going to introduce some level of novelty? So, the example I use, is if you've ever been to a restaurant and one of your kids is just having a fit and you pull up a silly 99 cent game on your phone, and you hand it to him, and all of a sudden now they're pacified.

[00:07:05] Somebody willing to be like, well, that little balloon game, that's silly, that's not even worth doing. But in that moment, not only is it relevant to you, but every other patron in that restaurant. And so, it's really, really important to realize that we're not centered or we don't exist for output, we exist for outcomes, and what outcomes are we achieving at the business level?

[00:07:31] And so, a great way to I think to measure that is, what is the engagement on your products? Do people love them? And secondly, is how long does it take from an idea to go from conception to production? And from there, there's a ton of things that you can slice up to to measure that.

[00:07:53] So, hopefully that answered your question. It is going to vary a little bit from organization to organization, but those are the two I think really really important things is, do people like what you're building? And how long does it take to conceive something and then build that thing?

[00:08:09] And companies that are very, very good at this, they are constantly putting things in front of people that they love and they keep buying it. I think Apple is a really good example of this. Most of their releases are iterative. But, they have a way of building things that people love.

[00:08:29] I would say halfway through my career when I realized that, I don't like code because I just love the sound of my fingers clattering on the keyboard at the middle of the night is that, when you build things that people love and you actually can capture that moment.

[00:08:45] So, at one point, I worked for Shutterfly, and it was always interesting to me because I I worked for Shutterfly, and they'd always be like, my mom loves Shutterfly, my girlfriend loves Shutterfly, I love Shutterfly. And I didn't really get it until I basically had to burn through some coupon codes and I purchased a book that from a Grand Canyon trip and I'm holding this in my hands and I was just floored that the code that I'd written translated into this physical book.

[00:09:18] And that fundamentally changed the way that I think about programming as a whole is that programming is just a means that the end is really I think, a deeper connection and a really creating value for the broader population. So, I know that Mark and I are very much philosophically aligned on on this particular point, which is why funding masters exist.