Focus on the Basics
You have the idea, rough thought about implementation. Now how do you go about implementing a concept/idea into an actually working proof of concept. Its easier than it sounds, and often times when starting the implementation of a concept you realize you may have bitten off more than one can chew. Thus begins the goal of defining the base, and features. What to define the base to build on? And what is a feature? With a product like Medarwin, we are toying with the concept of Marketing and software/hardware playing hand in hand. This may sound redundant, but the marketing is the front facing aspect while the software/hardware is the legs/hands that do all the work.
Thus building the legs/hands is what I consider the base, and the rest as features. In the first conversation with Aashish/Aditya (co-founders), I noticed that we were trying to include too much in our first product. They had a great vision for our product, but one, which had to be broken into a base, and features that would make Medarwin a good great product. Thus began my focus to develop the guidelines for a base with only the absolute basic goals of our product: to control what was being displayed on our LCDs from anywhere.
As most developers know: If you start to develop too much code at one time you will get lost in its total complexity and it will not come together. Thus the task of breaking the goal of displaying ads on to any LCD was broken down into specific parts These modules: Blowfish, Lion, and Mustang are the base for our product.
As we defined what each module would contribute towards the final goal, we slowly started to realize we were missing a critical piece to the puzzle: A Web Developer. There is a saying here: “out of all the people you hire in a start up: 1/3 are friends, 1/3 are referrials and 1/3 are new hires.” Our Web developer (Jan) is a past co worker at Netapp, who demonstrated great command with PHP/AJAX/JavaScript in developing online content.
Thus he was critical to the first module to be finished, as it is the interface to control the LCD from the Internet. This is probably the most important part of our product since it is what the user interfaces with. Users will create most of their impressions about our company through this web-based application. This is where Jan was great; in a brief amount of time he developed a working application that fills the basic functions of scheduling, grouping, and moving ads around in an organized fashion (this is one of the bases).
Next piece of the puzzle is the LCD control program called Lion. This application has a lot of value as it transforms the LCD into a remote display. It loads as soon as the ebox (low powered PC hardware) is turned on and begins displaying ads that are allocated to that timeslot. Eventually this application might end up having a simple UI for debugging, and changing settings to that LCD but for now that is beyond the basics. Simply downloading ads, and displaying them correctly is what we need to be focused on.
Lastly is our schedule transfer agent Mustang. This is a multi-threaded server application that retrieves Schedules from the database and sends them to Lion. It also handles sending updates to all Lion clients. Most customers will probably never even know about this software since it runs in the backend with no direct interaction. Performance of the module is the focus for this piece since eventually it will be receiving hundreds of thousands requests a day.
Now you have an idea about the process we took to take our concept into implementation with a total breakdown and explanation of what parts there are to Medarwin, A side note: the great part about this system as everyone knows is the ability to work in parallel, but the con of it is the issue of piecing it back together. There in lies the devil with issues in coding that surface. Hence when painting your next big idea be sure to map out how you can break it down and analyze the pros and cons of your methods.

