#begin
The next section of the book dives into prototyping, let’s take a look. They start off by saying that many industries use prototypes to try out specific ideas since prototyping is much cheaper than full-scale production. Think about SpaceX testing these raptor engines on these test stands. This is far cheaper than actually firing off a prototype into space, when you don’t even know the engine is going to work. I’m truly amazed by the speed and accuracy SpaceX iterates on actual physical products like their engines, let alone their software. It’s really great to watch. Another great example is in the Formula 1 they use these wind-tunnels to check the aerodynamics of the race-cars. Imagine if the drivers had to manually test all this on a test-track. The process would be very, very sluggish. Nowadays, we can even simulate the aerodynamics before even entering the wind-tunnel using software! How awesome is that!? So these are just 2 very clear and practical examples of prototyping.
But in software we use prototypes in the same function and for exactly the same reasons; to analyze and expose risk, and to offer chances for correction at a greatly reduced cost! I think this is such a great line by the authors. Another interesting thing about prototypes they mention is that fact that prototypes don’t even need to be code based, although they are many times. But they can also just be a couple of post-it notes, or maybe UML diagrams on a whiteboard, or some wire-frame using popular wire-framing tools like Figma.
Prototypes are designed to answer just a few questions, not all. So you might need to create multiple prototypes before you have all the answers to write the production system. It’s really important to focus on just a few questions or answers, maybe even a single one since it allows you to really focus and narrow down the solution of the prototype and ignore all the dirty hacks. So often, prototypes have poor performance, or they don’t have a UI or maybe work without proper database or web connections. This is all perfectly viable in a prototyping sense. But sometimes there are just far too many unknowns, and this is when tracer bullets might be a better way to explore it according to the authors.
And there are a couple of things that you would want to prototype, like: Architecture, new functionality in an existing system, structure of contents of external data, third-party tools or components, performance issues and user-interface design. Just remember that prototyping is a learning experience and thus the value lies in the lessons learned not the code produced.
I think this is such a great way to describe it. What an awesome line. Prototype to learn!
Next Andrew and David provide some tips on how to build prototypes. So what details you might be able to ignore for example. They start with correctness. Prototypes often use dummy data where appropriate. I use this approach many, many times when implementing something but I need to wait for the back-end team to finish up the endpoints. So we discuss how the data is roughly going to look like and I mock it all out so I can start development on the front-end in Unity3D of course. But also, a prototype can be very incomplete. So don’t aim for completeness. I mentioned this before as well. You might make multiple prototypes in order to check out viable solutions all specifically aimed at a subproblem. This is perfectly fine. You don’t have to cover all things in a single prototype app if it requires less time when you could simply create 2 or 3 apps more quickly.
The next thing to look our for is robustness. Prototypes are NOT robust, error checking is probably incomplete or missing entirely. Even if you move from the “happy” path, the application might crash and burn. So when giving a demo don’t go to contested territory. But this is perfectly fine, this is what prototypes are for.
And the last thing is Style. The authors say that prototypes probably don’t need much documentation or comments. When you are done prototyping you might document your findings, but that’s about it.
Describing all of this really drives the point home that prototypes are supposed to be throw away projects. Never should you have to continue development straight from your prototype to production. Because the short-cuts, all this technical debt will at some point in the future slow you down. This is a very important concept mangers need to understand because if they don’t they’ll see it as wasted time. But alright, let’s continue with the book.
Next Andy and David talk about prototyping architecture. It’s nice that they mention this specifically since architecture is inherently more abstract and maybe difficult to actually prototype. A prototype that tests a single feature or workflow in a very simple app or even a paper model does not need to function properly. But when you are testing architecture you really need to have something remotely working. How else can you verify your architecture works? So here they provide us (the reader) with some questions you can ask yourself.
Are the responsibilities of the major components well defined and appropriate? Are the collaborations between major components well defined? Is coupling minimized? Can you identify potential sources of duplication? Are interface definitions and constraints acceptable? Does every module have an access path to the data it need during execution? Does it have that access when it need it?
I think these are indeed very good questions to ask. These questions drill deep into the architecture and as we have learned from Clean Code and A Philosophy of Software Design, well defined components with proper collaborations, low coupling and clean interfaces are very important in order to keep complexity creep in check and create a clean code base.
And next up is the last subsection of the prototyping section which is called: “How not to use prototypes”. And yeah, this drives my point of prototypes being disposable home. They mention it specifically: “Before you embark on any code-based prototyping, make sure that everyone understands that you are writing disposable code”. Prototypes can create this illusion with management or customers that there has been a shit ton of progress is just a little while.
So the authors offer a solution, and I quote: “If you feel there is a strong possibility in your environment or culture that the purpose of prototype code may be misinterpreted, you may be better off with the tracer bullets approach. You’ll end up with a solid framework on which to base future development”.
And again, damn, this is so awesome. I can’t emphasize enough how much I like this explanation since I’ve ran into this exact problem many, many times. And I’ve also made the mistake of taking a prototype to production. So I should have taken the tracer bullet approach here. But I’ll provide you guys with a funny, well I can call it funny now. But I can give you a funny example of how prototyping code screwed me over once.
So… a customer of ours needed something like a 2D RTS game made in Unity3D. It wasn’t a true, real-time RTS but more of a strategy planning tool. So you could setup a map with troops and vehicles and then plan out multiple steps on how to complete some mission. Now, a colleague made a really cool single player prototype for this that showcased some of the basic features of the application. It was however my job to continue this project since he got switched to another project.
So I took the prototype, since it was already included in the estimation and throwing it away seemed like more work than refactoring it. But, I should have thrown it away because there were some really annoying short-cuts taken in the rendering part of the app. Another fun aspect here is that, this application was supposed to be a multi-player app, and the entire prototype was oriented towards a single player. And everyone who has ever programmed a multi-player game knows that, one does not simply convert a single player game to a multi player game. Even more so, this game needed to run on a private network, without a main server, disconnected from internet! So who-ever started a map first became host and other players could join. And yeah, I also had to build host migration, which was a pain in the ass. Host migration is when you have a some client that acts as host, and for example 3 players who joined him, then the host leaves the game for whatever reason, another player has to take over the hosting responsibility. And remember, I needed to build all this in a private network, so no cloud solutions for any of the multiplayer functionality; no web discovery, lobbies, connections, nothing. And the best part of all this, it was estimated to take 2 weeks of development, hahahaha. The problem here lied in the fact that, the one who estimated it, thought that we could use Unity’s Unet solutions, but since we had a hard requirement to run it on a private network, which was closed of from the internet and without a central server, we couldn’t use any of it, apart from the actual network messaging system. But I really regretted using this since now I had a hybrid of custom TCP code and Unity3D messaging. I should have gone fully custom made, which I eventually did in later projects. So the moral of the story is, it took this prototype which was oriented towards single player, which I needed to make feature complete plus add this custom networking solution which was estimated at 2 weeks but took me like 4 weeks to build. In hindsight, the person who built the prototype should have written the production version as well. But, because of planning, this were different. It was a great learning experience though, one that I will not quickly repeat.
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments