Rules of life in IT projects

For all the time I worked in IT, I took part in various fields of activity. I was both a team leader and a developer and project manager. He led large and not very projects, among them were both successful and not very. I worked with both professionals of the highest class (at least that is what I considered and still consider these people to be) and with not very experienced colleagues. I collaborated both with people who have worked in IT all my life, and with those whose interests and activities lie in completely different areas.
All this time I studied something and continue to study to this day.

After each completed project, in addition to the pleasure of the work done, there was also an understanding of what was done well and what could be done better.

Today I want to share those tips that I myself would be glad to hear when I was just starting out.

The simpler the solution, the more reliable it is.

In a solution with a lot of code, it is much easier to make a mistake. In addition, the correct decision should be obvious and understandable.

Not worth the inventor bikes

If there is a ready-made framework, or a library that you can use, use it. Do not write your own.

Logic and data types are best placed in separate assemblies.

When developing even a not-so-large project, it is worth separating the logic and types separately. This will make it easier in the future to test and reuse code. It will also reduce time costs if necessary to expand the project.

Open Source Must Be Used Wisely

If you take an open source project as the basis of your products, do not immediately rush inside it and write a bunch of code. With the release of new versions of the main product, merge may turn into a headache. If possible, you should allocate your code into modules and individual code files. If you decide to radically change the code, you need to fully evaluate all the risks and possible problems in the future.

Do not immediately write a platform

It is better to solve the problem. Many developers (including myself sometimes suffer from the same approach :)) immediately seek to write a universal solution for everything at once. Should not be doing that. It is often better to solve a specific problem and get a result. The time spent on creating a universal solution may not pay off, and often will not be in demand in the future. In addition, the more universal the solution, the more often it is more complicated and limited in use.
Often, this approach is for beginner developers, so the advice applies primarily to them - before you start writing such a solution - consult with your teammate whether it will be useful and in demand. And only if you get a positive answer, is it worth starting such work.

CMS is not a panacea

I often saw web projects that began with the fact that some popular CMS was being installed and the product was developed by “wrapping” code on it. The result was a floppy mechanism that used CMS functionality by 10%, and 90% of the code was overloaded and unreadable, so we had to take into account the structure of the CMS itself and the structure of its database.
It is much more effective to write a solution to a specific problem than trying to adapt a clumsy CMS for this.

Subject area most important

In all projects, follow the priority: Subject area -> Architecture -> Administrative tasks
The product is created for the client, and not for the developer, or system administrator.
I have to face situations when the administrator begins to tell developers how they are better off writing an API for the product. There were also developers who suggested that the client abandon the functionality, since the CMS with which the developer knows how to work does not support him. This approach is unacceptable if you really want to create a quality product.
The solution is created primarily for the client, and not for the programmer or administrator.

Optimization is needed only where needed

Sometimes I meet developers who say “I will not use the Entity framework, it generates inefficient SQL”, or “Using linq is syntactic sugar! Cycles and busting are better. ”Yes, sometimes not all things that are convenient will be most effective in terms of speed. But are performance percentages worth reducing usability and increasing code?
It is often enough to isolate two or three “heavy” functions into a stored procedure and wrap its call through the Entity Framework, or to optimize specific bottlenecks in the code, than to completely abandon the advantages that new technologies provide.

Readable code, better than re-optimized

In most cases, code that is conveniently readable and understandable is better than highly optimized but incomprehensible.

The tool should be comfortable

It happens that a new technology comes out, a tool, or a product appears that gets wide publicity and admired reviews. But in fact, the tool is not yet technologically ready. The introduction of such a tool, despite the apparent promise and technological effectiveness, may adversely affect the productivity of the team. And the advantages may not cover the disadvantages.
The tool should first of all be convenient and solve the problem.

TK should be

Even poor TK is better than no one.
I also met such projects where the project documentation was not available at all and a lot was at the level of verbal agreements. At the same time, the sizes of such projects were very different - both small and quite large.
Even if you are in excellent relations with the customer and fully trust him, all points must be fixed. And even this does not always help. Understanding of the same terms and descriptions can radically differ among different project participants.
So I happened to be at a meeting where only a basic understanding of domain terms was discussed for several hours. At the same time, development has not even begun.

It’s better to use a finished product than to write your own

There are many situations when a developer or a client decides what is worth writing his decision. In fact, somewhere in half the cases, this is not worth doing.
Development is always a long and expensive process. Therefore, even if it seems that writing your own analogue is easier and cheaper - in 90% it is only an illusion.
If there is a similar solution on the market, it is better to purchase it. It already exists and is already working. Here and now.
It’s worth writing your decision only if all the project participants are aware of the risks and understand that the process will be lengthy and expensive.
Clear signs that it is better to buy and implement than write:

• there is a product that covers the intended use case
• there is a product that covers the intended use case after a specific configuration
• There are several products that, when interacting and integrating, cover the intended use case.
• there is a product that can be expanded with certain functionality (add a module for CRM) and after that it will cover the use case

When it makes sense to write your own:

• the decision maker knows exactly why he starts development
• there is no product on the market that could implement the required functionality
• the company has enough finance to not only invest for a long time in the product, but also to engage in its support later
• You are a startup, and completely different criteria work for you

In addition to IT, there is much more in life

This tip is the last on the list, but not in importance. I didn’t just put a photo from ONE ☆ LIFE Everest Expedition organized by Artemy Surin at the beginning of the article. For so many in our profession, IT has become not only work, but life itself. I myself spend a lot of time behind the screen of a laptop / tablet / phone. But besides this there are things that also give many of us a lot of pleasure. For some, this is hang gliding, for some, reading books, sports, traveling, chatting with new people, collecting, drawing, writing.

I would like to wish everyone - not only work, but also live!

PS Special thanks to MarcusAurelius - for a preliminary review of the article and useful comments.