Jul 17, 2017
Why do we still not know how to develop projects properly?
Honestly, I do not know. But I think we are making one big mistake and I will try to explain it here.
Let’s talk about long-term projects that benefit the business and need to be developed and maintained. During this time, entire teams around the project may change, including management. This leads to the fact that the project becomes difficult to manage because knowledge of the project is partially lost or scattered over many people. Things get even worse when looking at the code left by developers who left the team. Even if the team does not change, it’s difficult for us to understand our own code. At best, this will lead to a rewrite of the project from scratch or the Customer deciding not to develop the project at all. It is not effective, looking at how much it costs. This, in turn, will also have an impact on business development. But let's leave the business to customers. To prevent this, we need to find a new approach to project development.
The biggest mistake is that we work together on a project instead of working together through the project. Sounds strange, yes? I will explain what I mean.
This is how the traditional scheme of work looks like. And this at the best-case. The manager describes the customer requirements, wherever (e.g., Excel, Trello, Jira). Developers try to break them into tasks, communicating with each other through communication tools (e.g., Skype, Slack, Mail) and making meetings or phone calls with the manager. After this, developers write code based on accumulated knowledge during all this communication.
Notice, Manager gives Customer Requirements. It is a one-way direction, I mean, he doesn’t receive feedback in the same way, through Jira, Trello. This contributes to the loss of knowledge about the project because no one records meetings and phone conversations. I call this the leak of knowledge.
After one of the developers leaves the project, knowledge is lost because his decision is nowhere written.
At the end of the project, the customer receives the product as a hosted application and only source code, without any documentation and manual, about building and hosting the project or why we take these architectural decisions.
This will be a problem for another team that will continue developing the project and for us.
That’s what I mean by “working together on a project.” Let’s take a look at how the work looks through the project
In this case, we see that all communication between a team occurs through Tasks, which is in the same place as the code. (it can be Jira with Bitbucket where on Task we can attach code branch on which we work or GitHub with own Issues). Notice that the Manager, as a full member of the development team, participates in the division of Customer Requirements into tasks. The whole process of knowledge sharing is through Tasks and comments to him.
No piece of code should be written without a task. No more undescribed problems. All conversations and making decisions now are available to all through Tasks.
This is a good example of how Open Source projects develop.
In this post, I’m not going to disclose why this approach works better or how to organize processes to achieve this work style. All the answers to questions you find in Yegor Bugayenko posts, and the author of the new software development methodology XDSD. Thanks to him for this.
In short, we must keep our accumulated knowledge somewhere in an understandable form and have one source of knowledge about the project. That the project itself had value without us developers, I mean it must be self-describing and self-sufficient.
Probably you have already sighed. I apply this methodology to the project and solve all my problems. It won’t! Even if you implement this approach, one big problem remains. Even if you implement this approach, there remains a big problem.
Communication through Task is only 30–40% of all communication through the project. We, the programmers, mainly communicate through the code we write. I mean that every day we read code which is written by another developer (e.g., Unit Tests, Code Review), who outlined his thoughts about a task through a piece of code.
And if we do not improve the understandability and readability of the code, we will fall into a bottleneck, which depends on the project development velocity.
How to write good code; this is a topic for another article.
Also, if you noticed, I did not mention Agile software development principles and Scrum as one of its realizations. Because there’s a lot written about Agile already and in Scrum, there is something, the lack of which saves us from many problems. I mean meetings. No more Scrum Master needed, which should protect developers from management, and many other side effects. It reminds me of a shepherd protects sheep from wolves :)
