Building a systematic approach to web development projects:
from start to success

We discussed how to set up a project before actual development in my previous article. Now it's time to discuss the project composition. According to my personal experience it is usually easier to pull together what is already done than to create a project from scratch. This mainly depends on what legacy you inherit or leave behind. I focus on what you should specifically notice and suggest you a short roadmap to run a front-end project in this blog article.

Understanding the project

Before you plan something, you need to understand what project you have to implement. I personally identify a few project categories. They include:

A handicraft. This is usually a project aimed at creating a certain graphic concept and further selling it to investors. The main features of this type of projects are:

• Insane documentation. The basic idea is understandable, but use cases are sporadic with countless logical gaps.
• Tough deadlines. Up to 3 months from writing documentation to the finished prototype.
• There are no development plans and no further maintenance.
• Small team. Usually up to 5 people, including designers.
• Lack of business processes. Chaotic interactions based on interpersonal communication, clarifying or inventing fundamental features on the go.
• Team roles are blurred. Each member's duties are not explicitly indicated with no related areas of responsibility.
• There is no real data. All data is generated for the sake of good-loooking and nice display.
• External dependencies are largely used to speed up the development.

A startup is a project that is configured to implement a specific idea with subsequent development. Usually, these projects are developed in a spiral model and, for this reason, have almost the same distinctive features as the first type (a handicraft):

• Clearly outlined milestones. At least the deadlines and the list of must-have and should-have functionality are fixed.
• Bearable documentation. Preliminary analysis has been made, milestones and deadlines have been set. Task details are often clarified during a sprint. Waterfall methodology dominates despite of publicly declared Agile.
• The average deadlines for the delivery of the main functionality are from 6 to 12 months.
• External dependencies are used at the very initial stage with subsequent replacement by proprietary implementation.
• Small team. Usually up to 7-10 people.
• There is a distinction of team roles, but particular responsibilities are still blurred.
• The project may mutate. The holistic concept of implementation approach may change. This is usually caused by the investors' requirements, bad initial idea or errors in the architecture.
• Conditionally live data. The concept can be tested on focus groups or data can be parsing from third-party resources. But this does not happen too often.

An information system is a project with future integration with third-party services:

• The development plan is in place.
• Clearly written documentation. At least API is documented.
• Work-arounds may be required to integrate with third-party services or rebuild parts of the system.
• There are intermediate releases, hot fixes.
• The team is of medium size. Usually from 10 to 20-30 members.
• Clear distinction of responsibilities.
• Security requirements: use cases leading to a system crash have been written following the analytics stage.
• QA is taken into account.
• Works are executed under the Agile methodology.
• Backlog is usually there.
• External dependencies are used only in case they are expensive to implement. Proprietary resources are priority to use.

An isolated system is a large-scale project designed to serve the specific client's needs with further development.

• A specific customer.
• The development plan is in place.
• Development documentation is in place. Additional documentation is written for users as per client's request.
• User access rights are differentiated.
• The backlog is most likely in place.
• The team size is usually larger than average. As a rule from10 members to infinity.
• Agile is used. Extra tasks that must be implemented at any cost occasionally appear.
• Unexpected demos. Management sometimes perform demos of the system, so a working test branch is always nice to have.

SaaS product is a heavy project with a flexible configuration and further customisation for a specific customer.

• Multi-modular system. The system is divided into several components, which can be used separately, even beyond the scope of the specific project.
• Proper planning. At least development costs of all features are estimated. Refactoring and upgrades work are usually taken into account for estimation too.
• Comprehensive documentation. The major part of the system is well described, including test cases.
• No external dependencies are used, proprietary component implementation is favored even if there are third-party counterparts.
• Multiple development teams. Everyone is responsible for their components whether it is back-end or front-end.
• Total tests coverage. Auto, unit, regression, integration tests are widely applied.

These types are very conditional and most often a particular project is a combination of a few types. All these types can mutate into each other, depending on the cost of the upgrade. For example, a project was originally a "handicraft", and then evolved into an "isolated system". Usually this leads to a complete or mostly complete rewriting of the system or its refactoring. This is hardly economically reasonable. For the same reason, you might want to first understand what type of project you need to create from scratch, and try to forecast its future.

To determine the project type, I put together a few questions below. By answering them, you will be able to define what you are dealing with.

• What is the project goal?
• Full feature list to implement?
• Is there any documentation available?
• What are the deadlines per each milestone? Exact dates preferably.
• Is integration with third-part systems planned? Is API development planned?
• Is there any legacy?
• Team size?
• Who is responsible for what? Who sets tasks, who accepts, who has the right of veto.
• Are there any further development plans? Which ones?
• Who is the customer?
• Is there a budget to purchase out-of-the-box solutions?
• What methodology do you plan to use?
• Are there any competing solutions?

The list is not long at all. However, for some reason very few people think about these questions before starting works. You can reasonable ask why I need to understand the project type? You always have to implement a project so that it exists forever without any issues. By and large, you are right, though there are nuances. These nuances are resources and deadlines. Remember that we work for the business profit and have to achieve goals. And that's where it becomes important to know the project type. Bearing it in mind, you can redistribute resources properly to achieve the ultimate goal.

Choosing the technology stack

The gold rule here is not to use supernew technologies, but they should not be outdated, too. If a tool or framework is new, it can lead to the following issues:

• Lack of advanced-level professionals.
• Future development: if a tool is too new, it can be discontinued in case it does not become popular among developers. Alternatively, the tool can get deprecated if it is too old and you will have to fix potential bugs on your own.
• Lack of ready-made solutions for new technologies, and lack of updates for the old ones.

This list of issues is relevant not only for technology selection, but also to third-party dependencies. All of the above can bury the project.
Before you choose something specific, think for a while. A good advice here is to create a simple table of benefits with importance indicators.

An example of such table:

The table indicates that the main technology selection criteria are "online forms" and "routing". The simplicity of creating animation for this project is not that important. Now update the table by adding technology columns. In our case there will be two of them.

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:

I guess it is obvious how to use this table. Just exactly the same as the previous one, except that you can't use particular values here, but yes or no only. Anyway, you can always use outsource custom software development. Please also feel free to populate the table as you feel necessary.

Hope this article help you to build a more systematic approach of software development and achieve new career prospects!