Technical specifications and architecture in a solo project. Achilles' heel or Sisyphean labor?

In the last article, we looked at the basic rules for combining third-party projects with full-time work. Now I will try to show the processes and stages of such projects in a more atomic way.

Let's start from the beginning – drawing up technical specifications and designing the system.

Essence of the question.

There is an opinion that in solo commercial/pet projects it is easier to keep things simple. The code is written by one person, there is no review, scalability is often not needed.

If the work is paid hourly, the question arises whether the customer should pay for the preparation of documentation for the project.

But even here there are pitfalls and unobvious benefits, both for you and for the customer. Let's take a closer look at the issue.

TK.

Business coaches, motivators, info-gypsies – they all promote a clear and simple idea: you must have a clear plan. This is how it is, remember how you come to work in the morning and don’t know what to take on, which way to approach it.

So the TK is the plan. Clear guidance on what, where and why should be pressed, pop-up, sound.

TK is a metric by which you can evaluate the work done. The more specific the requirements in those. task, the easier it will be for you to organize your work.

How to draw up technical specifications and get paid for it?

Companies have managers, analysts, and dedicated processes aimed at collecting business wishes and converting them into business, user and functional requirements.

For us, this approach is an unaffordable luxury, because the customer wants to receive everything yesterday, but does not want to pay for “scrawling” papers. How then?

Firstly, you need to explain to the customer why to draw up the technical specifications. The most obvious benefit is saving time. And time is money. You can say so directly – technical specification saves money.

Remember that every minute you spend planning saves ten minutes of your work.

Brian Tracy.

Secondly, start collecting technical specifications as soon as the customer starts talking about the project. I am sure that we can all do just fine without business and functional requirements, forming technical specifications only from use cases.

Don’t be afraid to ask the customer questions like “what happens if you click here, and if you click here?” This will help you in drawing up the technical specifications, and will give him an extra opportunity to talk about your product (don’t forget to praise the customer’s ideas so that he will tell you as much as possible).

Be sure to structure your answers. The technical specification should answer the questions:

• what does the system do?

• What parts does the system consist of?

• who are the clients of the system?

• what customer groups are there in the system?

• How do customer groups use parts of the system?

Accordingly, the larger the system, the more technical specifications there will be.

Architecture.

Many novice developers do not distinguish architecture from structures project. Architecture answers the question “how the parts of the system interact with each other,” and structure answers the question “how the parts of the system are divided into files.”

The structure is directly dependent on the architecture. The architecture depends on the business processes.

The minimum element of architecture is a component. The minimum element of the structure is a file. a component can be represented either as one or as a group of files.

class SubscriptionCostCalculator {
  int calculate(int baseCost, int? discount) {
    return baseCost - discount ?? 0;
  }
}

From the above we can conclude: the number of project files and their complexity will depend on the chosen architecture. With the right architecture, each individual file will have a specific role in the project (I'm not counting system files, instrument files, and configuration files).

How to sell architecture?

Choosing an architecture also takes time, and you don’t want to work for free.

We all know that the customer doesn’t care how beautiful the system is inside, the main thing is that it works.

As in the case of technical specifications, the first step is to understand how the customer will benefit from a properly selected architecture. Scalability and flexibility are unlikely to impress him, but sustainability is a strong trump card.

Yes, good architecture greatly increases system stability. Thanks to this, the customer will receive fewer failures, resulting in less downtime and more money.

Conclusion.

The decision to “keep it simple” almost always leads to missed deadlines and additional costs. But we must remember that our budget and deadlines are strictly limited.

When I discuss stages with a client, I offer two options:

1. I start with design, then write code.

2. I'm writing code right away.

After this, I explain that in the first case the first tangible result will be A little Laterthan in the second, but the total period will be lessbecause they will possible errors and associated delays have been worked out.

Soft keys, friends.