Developers Under Control

Nowadays, it is a common practice to give software developers freedom in choosing the activities they want to do. No boundaries in the technology stack, ability to work on a personal project, absolute freedom in tool selection — these are common trends in software engineering. However, there are some areas where developers have to be controlled and controlled a lot. Can you guess these areas?

Standards and Documentation

The very first and certain places where freedom is highly limited are standard related. Contract programming is a modern and convenient approach, and developers have no other way but to follow the interfaces provided by the architect. Same issue with the API — no matter if he likes it or not, a developer must follow the described format to interact appropriately with the 3rd party application. A similar issue exists in all other places where a developer has to reuse an existing code (e.g., open-source libraries).

Documentation is another area where the developer’s freedom is significantly restricted. The style, structure, and format of the documentation are usually strict. A reader has to have a feeling that the same person wrote all the documentation. So, when a developer is describing a feature he developed, he has to follow documentation guidelines to write a proper article.

Teamwork

Even when a developer can define his own standards, he still works inside a team. Teamwork has its traits — common language, standard tools, etc. If a developer wants to be a part of the team, he has to accept these conditions and follow them. Imagine a developer who speaks Chinese with English speaking team — no way they can do anything together.

Then each team builds its own coding rules or standards, which every developer has to take into account. It is almost impossible to work on a medium or big size project without having these rules. Otherwise, the project may become a mess very quickly.

Similarly, each team has its own development flow. It may include multiple stages (development, code review, testing), and these stages are also usually strict. There is no way a developer can merge code without a code review or passed tests on continuous integration server.

Even formal communication (letters, notifications, invitations) uses standard templates. And a developer has to use them to simplify internal communication to do not sink in bureaucracy.

Project Management

First of all, project management sees developers as resources. It means that they have to be able to handle any task. And as a consequence, it means that the whole development process has to be highly standardized — and here we are returning to the strict standards again!

Then project managers usually managing multiple projects simultaneously. The most convenient way to do it is conveyor approach, and this is how most of the project management flows are organized.

Finally, there is no way a project manager is going to significantly adjust customer interaction processes only to give a developer the possibility to do whatever he wants. Each project has a financial goal to achieve, and such an approach may be the first step to failure.

Illusion of Freedom

After reading this article, every developer may ask himself: What about the freedom and creativity in software development?

Surprisingly, the answer to this question is in the question itself. Freedom and creativity are fine on the software development level, and this level only. But, if a developer has to interact with other areas, he has to follow the rules of these areas.

However, it does not mean that these areas do not need fresh air and modifications from time to time. It only means that such modifications have to be accepted and approved by all players of this big game.