Rules of life in IT projects

For all the time in IT, I participated in various fields of activity. I was both a team leader, and a developer and project manager. Led large and not very projects, among them were both successful and not so. I worked with both top-class professionals (at least that's what I thought and still are these people) and with not very experienced colleagues. I have collaborated 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 learned 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 have been done better.

Today I want to share those tips that I myself would be glad to hear when I first began my work.

The simpler the solution, the safer it is.

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

Not worth the inventor of bicycles

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 better to carry in separate assemblies

When developing not even a very large project, it is worth spreading the logic and types separately. This will make it easier in the future to test and reuse code. As well as reduce the time spent if necessary to expand the project.

Open Source must be used wisely

If you take an open source project as a basis for your products, you shouldn’t immediately rush into it and correspond a bunch of code. When new versions of the main product are released, merge may turn into a headache. If possible, your code should be separated into modules and separate code files. If you decide to radically change the code - you need to fully assess 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. Often it is better to solve a specific problem and get a result. Time spent on creating a universal solution may not pay off, and often will not be needed in the future. In addition, the more universal the solution, the more often it turns out more complicated and limited in use.
Often, this approach happens to novice developers, so the advice applies primarily to them - before starting to write such a solution - consult with a senior teammate - whether it will be useful and in demand. And only if you get a positive answer - it is worth starting such work.

CMS is not a panacea

I have often seen web projects that started with the fact that some popular CMS was installed and the product was developed by “twisting” the code on it. The result was a slow mechanism that used 10% of CMS functionality, and 90% of the code was overloaded and unreadable, so you had to take into account the structure of the CMS itself and the structure of its database.
It is much more efficient to write a solution to a specific problem than to try to adapt a slow CMS for this.

Subject area is most important

In all projects observe the priority: Subject area -> Architecture -> Administrative tasks
The product is created for the client, not for the developer, or the system administrator.
I have to meet situations when the administrator starts telling developers how they should better write an API for the product. Also, there were developers who offered the client to abandon the functionality, since it is not supported by the CMS with which the developer knows how to work. Such an approach is unacceptable if you really want to create a quality product.
The solution is created primarily for the client, not for the programmer, or the administrator.

Optimization is needed only where needed

Sometimes I meet developers who say "I will not use the Entity framework, it generates not efficient SQL", or "Using linq is syntactic sugar! Cycles and brute force are better. “Yes, sometimes not all things that are convenient will be as effective as possible in terms of speed. But are performance percentages worth reducing the level of ease of development and increasing the amount of code?
It is often enough to single out two three “heavy” functions in the stored procedure and wrap up the call through the Entity Framework, or to optimize specific bottlenecks in the code, rather than completely abandon the benefits that new technologies provide.

Readable code, better than re-optimized

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

The tool should be comfortable.

It so happens that there is a new technology, a tool, or a product that receives wide publicity and admiring reviews. But in fact the tool is not yet technologically ready. The introduction of such a tool, despite the seeming promise and manufacturability can negatively affect the productivity of the team. And the advantages may not override the disadvantages.
The tool should first of all be convenient and solve the problem.

TK should be

Even a bad TK is better than the absence of any.
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 size of such projects was very different - both small and rather large.
Even if you are in excellent relations with the customer and trust him completely - all items must be recorded. And even this does not always help. Understanding of the same terms and descriptions can be radically different for different project participants.
So I had to be at a meeting where only a basic understanding of the terms of the subject area was discussed for several hours. The development has not even started yet.

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

There are many situations where a developer or client decides what it takes to write his or her own solution. In fact, somewhere in half of the cases, this is not worth doing.
Development is always a long and expensive process. Therefore, even if it seems that writing your analog 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 is already there and is already working. Here and now.
Writing your solution is worth it only in the event that all project participants are aware of the risks, they understand that the process will be long and expensive.
Clear signs that it is better to buy and implement than to 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 a specific functionality (add a module for CRM) and after that it will cover the usage scenario

When it makes sense to write your own:

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

Besides IT, there is a lot more in life.

This tip is last but not least. I did not just put a photo from ONE ☆ LIFE Everest Expedition organized by Artemiy Surin in the beginning of the article. For many in our profession, IT has become not only work, but life itself. I myself spend quite 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 someone reading books, sports, traveling, meeting new people, collecting, drawing and writing.

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

PS Special thanks to MarcusAurelius for preliminary reading the article and efficient comments.