Prototyping the right way
A common trend that I see with Software Development teams is the absolute need to over-engineer prototype solutions. "Hey Mark, can you build me a website where I can upload the photos from my phone?". Two months later Mark comes back with a budget estimate of two million dollars to cover hiring and infrastructure costs and a three year roadmap... "Dude, I just want a website to upload my photos... It will cost me 3 years and 2 million?". Seriously Mark, why couldn't you focus on the goal, keep it small and simple? Why did you have to go "all-in" right from the start?
To be fair, this reaction can sometimes be explained when Developers work for unreasonable, non-technical decision makers. Almost everybody have heard of stories about entire Engineering departments getting blamed (sometimes even fired), when the accountable Engineers clearly stated that the product was not ready to be released; even so, the upper management ignored their assessment, forced them to release the product and inevitably things went sideways; now the upper, upper management is asking questions and who gets the blame? That's right the Engineers, who can't justify their case because at the end of the day they handled the release. In other words, they had the keys to the atomic bomb...
For anybody that have to deal with this kind of management, it's understandable that all scenarios must be covered right from the start. At the same time, any kind of battle will be lost against this type of management. So respectfully give them a book about modern Software Development strategies or tell them to attend a Agile workshop because their management style will not fit the current market.
Anyway, let's put this scenario aside and imagine that you are working with reasonable people. A prototype, just like any typical development task, where you can ignore the process and development guidelines/rules to get the necessary answers as fast as possible. So "divide and conquer" is usually useful to break down the problem in smaller chunks, but you can also take a more holistic approach: start by identifying the two main areas that can be handled individually (like user interface and functionality). Each major area can be broken down smaller pieces like: user experience, data persistence, testability, application logic, so on (areas might vary depending on the research you're performing). Additionally and most importantly, identify who are you doing this for and what are the expectations. Knowing your target audience (in the context of a prototype demo) it's absolutely essential to keep you on track.
Are you building this prototype for yourself? Great! What do you want from it? What do you absolutely need? Just to rephrase, try to keep it simple. The whole idea is keeping focused on your goal. But at the end of the day, you own it, so you do whatever feels appropriate.
However if your building the prototype for somebody else, you will need to focus on what the target audience is expecting. A lot of people, just focus 100% on the user-interface and user-experience, mostly because "eye-candy" sells (just look at what Apple has been able to achieve). To be fair, doesn't look as lazy as a PowerPoint and it gives the team a lot of breathing room, since users can glaze at a fancy UI, while the backend is being developed. It also gives the users the opportunity to experience some product features upfront, even if nothing is wired up. They will probably come back with a ton of ridiculous suggestions but at least you "kept the ball rolling". Just take everything that they say with a grain of salt, otherwise might get stuck on doing UI tweaks and never get the actual product working. Realistically, if you just focus on the UI, at the end of the day you just have a fancier interactive slide-show. It might look better than a PowerPoint, but it's still just a "fancier" PowerPoint. And yes, I'm
saying that the customer isn't always right. As a paid professional you should guide to customer to the right path and not blindly follow their orders.
Beside the UI, there are two others concepts that are commonly over-engineer right "out of the gate": data persistence and dependency injection. "Dude, it's a prototype!", you can worry about it later. "But I really need it!". So save whatever you need to a file, you don't need a full blown SQL server, ORM and data access layer, right from the start.
Anyway, I think I went a little off-road there, so let me get back on track. So let me give you a real example, something that I have seen before. The CTO goes to the Engineering team with a new challenge: "Alright team, let's see if we can build the next version of our current website, however for this project let's figure out if we can use a RESTful API to communicate with the backend. Our main concern is the search functionality. We don't know how it will work using REST, so do your research and present your findings in 2 weeks!". Pretty clear right? Based of an existing website, let's create a RESTful API. Since the search functionality is the boss's main concern, let's start there. Does the team have any other concerns? Great, write them down and try to find a solutions for those problems after you dealt with the search issue. What actually happened was quite interesting, the team started with the setup of the build controller, which from me was a bit pointless since they should be able to build and test any prototype on their computer. Then they created a solution for the project (obviously you need this) but instead of just creating a project for the new website, right from the start they created projects for unit testing, integration test, UI test, core and shared functionality, data access layer, logging, tracking and analytics handlers. Keep in mind, we don't have any functionality, but right out of gate we have a bunch of projects, that work mainly as placeholders at this point(first indication of over-engineering). Then they download and wired up a dependency injection framework (which a bit funny when there is no application logic); they moved on to setup a SQL server instance, pick a ORM, create the data access layer and wire it up; then the picked a logging framework, started conversions about monitoring and error handling, threw tracing and analytics concerns in the middle and the challenges kept coming. However what about the CTO's main concern? Was anybody working on that? (Team's response)"Well, we don't know how we will handle the search piece, but we have the initial setup ready...", as you might imagine the CTO was quite upset, since nobody come up with a solution for the questions he had.
A ready good rule to keep your prototypes lean is "once you're done, you have to throw it away". Gather whatever notes you need, just don't copy any code. This technique is usually enforced if follow a Test-Driven-Development methodology, since you lift all process constraints to get your prototype/research done, but after showing the findings the prototype have to be deleted. That way to don't have to worry about any technical debt created by your prototype development.
There are multiple interpretations of what a prototype should be and what's their purpose. In this article I consider prototype an research task that will help you figure out answers for some of the unknowns. It might help you prove that you can do a certain thing the way you envisioned, or even the opposite. It might help you figure out that a particular strategy, won't work on mobile devices (just an example). This is vastly different from a product in alpha phase. A prototype should be something you would be willing to throw away. Anyhow, just keep in mind that prototypes must focus on what's absolutely essential.
