Creating the Best Project Obsessed With Perfection
As software developers, we all aspire to create the best project. We want to write perfect code and deliver an outstanding product by using the latest technologies, the best architectures, and the best practices.
Think about various structures and architectures you’ve heard or experienced: CQRS, Minimal API, Micro Service, SSR, SPA, Rest, GraphQL, and more.
When learning these technologies or using them in a project, you might have been enchanted by the idea that every project should be done this way. If that’s the case, you may have fallen into a misconception.
Before starting a project, we must not forget that our main job is to provide solutions. We are solving a problem or a set of problems, so understanding the problem well and determining how we will reach a solution is crucial.
Using entities, CQRS, or GraphQL in every project won’t always be the right choice. For a small project handling basic CRUD operations, you can build an SSR project without preparing a web service, or if flexibility is desired, a simple web service can be created with a small REST API and JWT.
Complex structures used in previous projects, although familiar, can become a burden in small projects. It is important to understand the problem and choose the solution with a proper workload analysis.
Starting a large project with a monolithic structure or a single service can lead to an excessive workload and duplicated code blocks in areas like validation, business logic, and feature implementation. Eventually, almost the entire project may need to be refactored.
While understanding the problem is crucial for producing a solution, the chosen path to produce the solution should align proportionally with the project’s requirements and the business side.
The project’s delivery time, stages, forecasts, and the technologies and methods used can be disrupted or reach irreversible points.
This is precisely why the pursuit of the best can be a trap, for reasons like these and similar ones. Solutions produced without understanding the problem will eventually hit a roadblock.
Endless Projects
Unfinished tasks, new projects, shelved, outdated, abandoned projects—mostly, the attention-grabbing points are where the solution attempted with the tech stack matches.
Let’s consider this as a corporate decision. The necessity of solutions used in a project being proportional in terms of workforce on the employer side comes into play here. In a large project, how can we divide the project? How many people have access to this information and have the ability to intervene and add innovations?
In some projects, these questions are crucial, so making the right decisions from the start is crucial for the project to succeed.
In small projects, working as a team to reduce the workload can have the opposite effect. Cycles of waiting for each other within the team start, and efficiency decreases. When evaluating all these aspects, the question of what to do naturally comes to mind.
To solve the problem, it is important to estimate the foreseeable size of the project and adopt a realistic approach. Rather than adding infinite features to a product, if your solution is substantial, presenting it in small solutions as a whole product will be a good example.
Understanding the problem well and analyzing the solution, determining the capabilities the solution will provide, and how it will provide them are crucial.
Then, think about where additions can be made to the structure. If the project does not meet the desired feature, avoiding modifying the project and creating another solution to integrate into the project is essential.
In short, the algorithm of the product or at least its features should emerge as clearly as possible first. Then, the development process can proceed in a more transparent and understandable way.
(this content is “WIP” after the updates final version will be on linkedin.)