In large and complex systems that we are dealing with regularly, what makes our projects standoff from others is: a. Quality of the software b. Time line Both being mission critical, how good is it to have a prototype? After the “Process Oriented Architecture” hype, most approaches in mid level organizations have prioritized freezing down on the requirements first, then code. Users, functional experts and developers are required to bridge the gap, if any before a single line is written in any programming language. For a reasonably large and complex system it’s tough, if not impossible, to visualize the system in entirety first place. Building prototypes help achieve the common meeting place early. Most systems are refined and evolve to a great degree during their development. Develop and evolve is not the strategy we would like to have, but quantifiable units which could act as sub-assemblies to a bigger system should be the approach to building a better and more robust system. We should forget building a system, which is fool proof; a system is fool proof only when it is discarded. Most of the software systems built are discarded or never implemented. We should keep this in mind when we are starting off with our next project. Keep apart everything; Users of system are the most important actors to the system as they are the drivers of the vehicles that we build. We should always try and make them comfortable with the particular system and hence, prototypes. Prototypes bring us closer to the user community in a far more sensible and productive way than presenting them with complex logic and patterns that are more contextual to the developer and not the User. How should we plan the prototypes? When we have a reasonable amount of input from the User about a particular component. Most systems, be it large or small, can be divided into components or sub-assemblies that build a larger system. When we have identified such a component that can be presented to a particular User Group or community it should be built and put in sync with the User. This gives a better chance from the system’s point of view to find out enhancements, flaws, and bugs, so on so forth. An example would probably better justify what we really want to do. Let’s take the example of Microsoft Word that I regularly use as my document editor. I am really not interested in what “Templates and Add-ins” is when I am creating this document. Had I been the User when MS Word was being developed, I might not have appreciated the idea of Templates and Add-ins. Presenting Users with a tangible output, which meets their requirement criteria, gives a tremendous boost to the thinking process of User and opens up whole new spectrum of the evolution process of the system, which might otherwise become a bottleneck during implementation. << Best Practices - Programming->Classes/Functions
