This is a simple guide on how to choose the right technology for the right set of requirements while building a web application from scratch. Most developers and technical leads face this demand practically every time a new project lands on their lap. What constitutes the right decision? How do I ensure that I do not take up unnecessary technical debt?So before we proceed, let me iterate the reasons for following good design decisions.
- The choice of right technology for your solution ensures better estimates for your project
- It provides lesser cost to clients
- The solution takes shorter Time to Market
- The developers have less(er) coding effort, and by extension lesser bugs introduced (inadvertently)
- The quality of your project deliverables improves greatly
- Your clients have better Return of Investments, and by extension more conversions (as new client projects)
“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”― Bill Gates
The context of the above quote is very clear. A smart developer always chooses better tools to implement the solution, because the tools will handle most of the heavy lifting. This way, the developer achieves above and beyond the requirements, with little effort from his/her side, and assures quality of all deliverables. Check out the following slideshare for and interesting perspective on the same: http://www.slideshare.net/hugsheehy/diligent-or-lazy-was-bill-gates-rightLets take some examples of Web Technologies available to us. In my opinion, these can be classified broadly as follows:
- All MV* frameworks come under this category (MVC, MVT, MVVM, etc)
- These are usually language or technology bound
- The implementation of these, runs on either the server or on the clients browser
- Examples of server-side frameworks: Laravel (PHP), Django (Python) Ruby on Rails, ASP.NET
- Examples of client-side frameworks: BackboneJS, AngularJS, Silverlight
- These are usually solution bound technologies.
- As a result, there are a lot of such focused solutions available based on the type of solution required
- Some examples are given below
- Ecommerce: Magento, Zencart, Oscar
- CMS: Wordpress, Merengue
- LMS: Moodle on Drupal, SCORM
Use this rule of thumb: Always choose a solution bound technology when possible. Choose basic framework, only if there are no solution-based frameworks meeting (most of) your requirements.
How to make the right choice
There are no hard and fast rules on the rules to make your decision. I am sharing my opinions based on many mistakes from my past.
Step 1: Understand your requirements
- Talk to your clients and understand their ACTUAL end goals
- What are they trying to achieve through this solution?
- What are the pain-points that they are trying to overcome?
Step 2: Break down the requirements
- Once project requirements are gathered, break it down into logical modules based on business logic. Do not think of implementation logic at this phase.
- If a module is too vague or abstract, break further into groups of independent/interacting modules.
- It is best to have a design diagram showing the relations between each modules
Step 3: Identify the type of solution you are providing
- Once requirements are gathered and logical design in place, identify your core modules that solution is most dependant on.
- Now abstract away those components and try to describe them in a single word
- This will help you choose the solution type that best suits your requirements:
- If your requirements is predominantly a marketplace or Product transactions, then clearly its a Ecommerce project
- If the requirements focus on content delivery, then its a CMS solution.
- If the requirements involve data processing/computing, and various inputs taken from different sources (live or otherwise) or if the requirements are a collection of different unrelated components interacting in a unique fashion, then clearly the solution has to be some basic framework. This is the choice if there are no solutions available in the market meeting your core requirements.
Step 4: Research
- This is the most critical part of your design decision. Most mistakes and technical debts are made here at this point.
- As in previous step, once the core modules are identified, research about them on the Internet. Find out the most popular technology or solution in that field
- Ask on Stackoverflow and Programmer stack regarding any doubts you have.
- Choose the technology/solution that handles most of your requirements out of the box.
- Once a technology is chosen, we now try to handle the remainder of the requirements. For example, try to search for plugins or extensions that handle your special case.
- If no extensions are available, estimate the complexity of implementing your requirement in the above technology/solution. Chances are your requirements can be easily implemented with little effort. Most solutions are designed to make your life easy.
- In the unlikely case, that the coding complexity is too much, you need to rethink your choice of platform.
- Choose another platform that covers most of your core requirements (the slightly less than ideal case).
- Search for plugins/extensions to handle the remaining requirements.
- It is possible that the complexity of your coding the remainder requirements would be lesser with this new choice.
- REMEMBER: The more code you introduce, the more bugs you may introduce. This increases the QA effort required before release.