Based on the table data, apparently online forms and routing are weak in "Technology 2", while animation creating is similar to abracadabra. The resulting indicator for Technology 2 is 2. You ask why 2? It's simple! I specified ± for cases when the technology allows to implement specific functionality with some workarounds or when it is labor-intensive.
In our example, the "Technology 1" looks much more relevant with the total importance indicator of 4.3. I guess explanations how I got these sums are excessive. This table works not only with technologies, but with anything to compare and select from. Generally the more criteria you mention, the easier it is to make a choice. Architecture
Nowadays you are able to try a variety of architecture design services, but as a rule the majority of them are far from perfect, which can be critical for some people or just fine for others. I am an oldie, so I prefer working a pen and a piece of paper.
In order to prioritise works, you need to outline the main components of the system, and then choose the right way to build an architecture. There are 3 main approaches:
- Descending - developers first design the system from large components and then decompose them into smaller ones. Basically this type of architecture implies that the primary components are large nodes containing smaller ones.
- Ascending - developers first list small components and combine them into larger ones. The main idea of this type of architecture is to first create smaller details and assemble large units out of them.
- Monolith – this type of architecture is often referred to as "legacy". It can't be divided into components at all. It is a rigid structure. In case you want to make any changes, no workarounds will help. This is the worst option, but anyway it has the right to exist. Monolith is used to implement specific functionality without any plan for further support. Compared to ascending and descending architectures, this approach ensures the highest development speed. Well, just because you can close your eyes to many nuances.
The choice of the right architecture type depends on the project goals and the expected development speed. The descending method is used when the deadlines are not tight, and the number of large components is not significant. The main benefit of this approach is that it allows to accurately define connections between all modules. The only disadvantage of this type of architecture is that it takes time to design because of multiple action sequences.
The second approach is preferred when high development speed is required and the high-level architecture structure is not clear. The main feature here is a large number of small components that are engaged in multiple large components. The main advantage of this approach is possibility of highly intensive parallel development without considering specifics of related tasks. The disadvantages of this approach is that some components may not comply with the resulting high-level architecture requirements and, accordingly, you will either have to rewrite them or ensure possibility of their customisation. Project planning
When starting development it is very important to create the project roadmap. The roadmap is basically a timeline of the project development with features and deadlines for each one. Specific dates can be shifted of course, but if you do everything right and the project goes without unexpected force majeures, the delay will be 30% max. In fact it usually does not exceed 10-15%. Planning lets you easily track the project performance, delays and make necessary actions in a timely manner, including resource redistribution or increasing the team. Here's what you will be rewarded for
Any project begins with the documentation and the more, the better! So do not be lazy - document EVERYTHING. Yes, it is going to take time, but later it can save you from the wrath of the management, if something goes wrong without your fault. Furthermore the project will continue living after you leave, so new people will have to understand what you have created. That's will be tricky without proper documents. Conclusion
This article describes how to act and what to pay attention to when starting a development project. These recommendations are universal for the front-end development, back-end development, QA or all together. I deliberately avoided specifics on technologies to cover the subject in a wider format.
When you have to choose the technology stack, architecture type and define deadlines for your project, the following table can be helpful: