What is the difference between a prototype and a production level solution?

Question

This question is purely for learning and to step-up my technical understanding. I know there is no perfect solution and this question has possible never ending solution list but I think it's very important for every architect to understand the difference between demo and a live project.

I created many demo solutions in .Net in the past. I now have been assigned to architect and implement a production level web solution so I wanted to ask - on a very high level, what is required to convert a demo into a production level solution. From my understanding, this will require (other than functionally implementing clients' requirements):

1. Unit testing every method
2. Ensuring ~100% code coverage is achieved
3. Logging all exceptions and possible pointcuts - possible with AOP
4. Using interface design pattern, dependency injection, possibly by using a framework e.g. spring.net
5. Using performance counters and profilers for instrumentation
6. Applying appropriate security - i.e. windows authentication (if that's whats required by client).
7. Transaction management on every single method
8. Back up of the web application files before new deployment of solution

What else?

My question is more related to technical side instead of functional/documentation because otherwise we will go into another path :-)

Thank you.

Answer 1

I think the most important difference is that a prototype's objective is:
1. To prove that a problem can be solved in a certain way OR
2. Give client / management a feel of what the product would look and feel like

whereas the objective of a live system is:
1. To solve a certain problem / address an issue.

Notice that the objectives of the two are completely different.
Therefore, in my opinion a prototype should be thrown away before developing a live system.

This is also because a prototype is usually a 'quick and dirty' project, thrown together without any of the considerations you've rightly pointed in your question (like testing, performance, security and a lot more).
So you'd be better off starting a new, proper project, than trying to make a bad project better.

Answer 2

Not all of those things are required, depending on your requirements, or there might be way more required. If you know what I mean ;) Unit testing and code coverage are good things, but depending on how you go about other parts of the process, might not be required. Some would say that more important than performance profiling is well-documented code, or a training manual. It varies!

I realise you're looking at the technical side but hopefully you will understand my point, it varies depending on the non-technical side. Or at least, it should.

Using performance counters and profilers for instrumentation.. might be suitable, but might be massively overkill. Might not be required.

What you're missing here is failing to account for the context, scope and business requirements of the project.

By context and scope I mean - are you creating something to be used internally by a business? Customer-facing? Used by end-users? Is it in fact a jazzy version of Notepad, or a new RDBMS from scratch? What should be included will vary massively (massively!) by the project you are looking at.

By business requirements I don't mean the use-cases for the software, but the requirements of the project management / production process. If you insist you need all of those things for a production project, the cost will be reflected accordingly (very high). That could either mean it's over budget, late, or not even given the green light to start development.

It could be that more important than having a fixed set of criteria now is simply having a good production/development framework, high visibility and regular releases so quality can be assessed that way. It could be that no-one involved gives a crap about code coverage.

Answer 3

Interestingly, I think points 1, 2, 4 and 7 should already be done during the conception of your prototype, except that I don't think you should test every method in every class. Test the critical code, not whether get/set methods behave correctly.

Depending on the purpose of your application, where security is a big problem, point 6 may be critical enough that you need to achieve it in the prototype. Depending on the purpose of your application, where performance is the key, point 5 may be critical... You know what I mean. My opinion is that points 3, 5, and 6 may be necessary in the prototype if they are considered critical (point 8 is really valid for production applications)

Edit: it seems that my opinion differs completely from sJhonny's because I imply that I consider the prototype to be the basis/shell/skeleton of your future developments, so for me the prototype is not to be thrown away.

Answer 4

In addition to what has been mentioned already, in a production project you need the following (among others):

0-Choose an implementation methodology

1-Finalize and publish major requirements (including use cases, etc.)

2-Get the architecture right

3-Select the correct tools

4-Design database for performance

5-Produce your class design and workflow design

6-Determine and implement a strategy to integrate backed databases/data sources/feeds

7-Define and Implement security requirements

8-Arrange for physical implementation (Servers, connectivity, licenses etc.)

9-Plan for storage requirements and determine performance measures

10-Produce all artifacts and install in production environment

11-Test

12-Deliver final solution and implement feedback

Answer 5

The most important feature of production quality solutions is - in my opinion - robustness.

Regardless of what happens, the solution handles the situation sensibly, notifies those needing to know, and keeps going (if the error is recoverable).

Answer 6

There are two kinds of prototypes:

• Quick-and-dirty "proof of concept" applications that get "cleaned up" and become production code. The "clean up" stage tends to either be a nightmare, or it is really a "sweep the problems under the rug" stage, resulting in massive technical debt.

• "Mockup" prototypes or "wireframes". These can be paper-and-pencil UI sketches, or even interactive mockups done in a language where you can quickly throw this kind of stuff together without a whole lot of thought behind how it fits together. It should use fake data, no real architecture, etc. The point is that they give stakeholders an idea of what the system will be like, so that you can refine your requirements, but they CAN'T be used as part of your final solution.

I prefer the second kind. They get thrown out, because there isn't really a choice.

Answer 7

I say build it like a project with no demo, but now you can include what you've learned from the demo in your design. Initial coding can be bad even once you start production. You're going to have to refactor much of it anyway.

The real problem to address is your time contraint. When the decision makers want you to continue working on the demo, they're under the impression that much of the application is ready, so it won't take as long. I've heard others use this logic on why they prefer to show sketches to clients instead of overly-realistic mockups. Pay attention to the demo code because it may have discovered issues you never thought of and probably didn't document in this process. You now have to consider them (Overly simplified, but yes, the database may not be accessible for example.).

All prototypes and demos are not created equal. The entire code could be worthless or certain parts may have been done very well. It doesn't matter if it is a demo you have to know the difference. You wouldn't just throw out a legacay app and start over would you? Forget I asked.