Bad development practices that I still see in startups
Hi, I’m Victor. Twelve years ago I came to a web studio in Samara. This is how my development journey began. We didn’t have a git, CI/CD, testbeds, and much more. I saw how this hindered the development of the team and business. I had to pick up a rake by feel, discover good practices and implement them. Since then, he has worked as a senior developer in a Russian financial holding and a German b2b startup. He was a team leader in a foodtech project, CTO in educational startups for the Russian and Latin American markets – and almost everywhere at first I came across similar problems. Recently moved to Israel, began to advise a startup. And what would you think…
Below I have collected practical examples of how we shoot ourselves and our business in the foot, although it would seem that the goal in a startup is to “run fast”. And he laid out a diagram of how to fix it, which I usually use myself. She inspired me to write this post. You can find the diagram at the end of the post.
No Git, development is done on a production server
A classic story when a project starts with one developer. He does something, uploads via FTP, tests and edits directly on the production. Maybe somewhere there are repositories, but they are empty or not updated.
Then the business scales, developers are hired. And then something interesting happens. For example, once such a friend, who worked alone and without a git, lost a couple of days of my work. Fortunately, I’m used to using the version control system in any projects and situations. The question is, what would happen to his code if I shut it down… In order to sell the startup team the idea “git is needed, it will give backups and help scale”, I made a presentation and spoke at a Friday pizza meeting. And it helped. When the production went down, and the second developer was out of touch, at least I was able to understand what he was changing. And fix the bug relatively quickly.
No code review
I came to a project where there was no one left from the previous team. The task was to change one type of pagination to another. It would seem that business – go into the function and change in 2 minutes. But a replacement cannot be made, because the predecessor used a tricky scheme: copy-paste the code, into which he made some changes every time. In total, we have 200 occurrences and hemorrhoids with their manual editing for 3 days. I think this cunning copy-paste would not pass a review from any colleague.
But well, then I had at least time to sit, think and do better. Here is an example where the lack of a review turned out to be critical. New project. CRM, the basis of all business, slows down. It needs to be fixed, management is pressing. The developer decides to ignore the standard processes: code review, testing, running autotests. Just immediately push to git and release. CRM falls completely. It turned out that under stress, when “you need it right now,” the person made a mistake in the code. It’s much safer to have someone else look at the commit. IMHO, in critical conditions, you can ignore autotests if they spin for a long time. But don’t ignore the code review.
No CI/CD
On one project where I came, the guys released it manually via git pull. The site crashed regularly. For example, once they simply did not install packages. Support, business and users have accumulated questions to the team. After setting up CI / CD, the situation magically improved.
Another time, the presence of git and CI / CD helped us a lot with the same “release quickly”. We needed a German version of the site, and urgently and purely as a landing page for showing to potential investors. Having an automated process of deploying and creating new test servers based on CI / CD, we quickly trimmed everything unnecessary, raised individual databases, uploaded translations – and voila – turned the test bench into a site for showing to investors.
No transparent task setting process
My “favorite” story is setting goals by splitting a thread into 150 chat messages. Or in a personal
.
Once we had a general chat with a call center. And there was QA, whose tasks included filtering information in the chat, clarifying details, and if a bug really popped up, start a task in the tracker. But the call center employees quickly realized that if they write to the chat, they will be asked all sorts of clarifying questions in all forms, asking for screenshots, URLs and other “complicated” things. But if you write directly to “tester Zhenya”, in half of the cases he will fix something quickly through admin access.
QA was completely sure that he was doing a good deed, but in fact, due to bugs unknown to others and the scale of manual work, we were losing money. Everything was revealed after the person left the company. We were bombarded with a flurry of new information and small but nasty bugs that had to be urgently fixed.
And somehow managed to stop this. There was an “important” task, integration with a large client. The manager, bypassing all processes, went to the developer to set the task in his voice: “You don’t even have to think, just do as I say.” Fortunately, the team has already learned how to work by processes. Discussed on the daily, added to the tracker. Come explore and ask questions. It turned out that by the “without thinking” method we could merge the entire commercial base.
No rule “1 issue = 1 branch in code”
We were making a new big piece of the system that paying customers were already waiting for. The launch was supposed to bring us a lot of money. Every day of delay, on the contrary, ate this money. Together with the team, I decomposed everything into separate, as independent pieces as possible, so that we could release the functionality as quickly as possible, and sawing various Wishlist and finishing touches is already in the process.
I created 10 tasks in the tracker, but the guys decided to do them in one branch. As a result, the deadline was yesterday, but we can’t release it: there is a critical bug in one of the non-critical tasks that you can’t fix quickly. At the same time, if not for the common branch, we could easily release the remaining 9 tasks – and start the system. After debriefing, the team adopted an approach. But interestingly, when I moved to another team, we had to go through this “delightful” experience all over again.
As you grow, autotests do not start
Some startups live for a long time. And hoard legacy. I myself came to autotests precisely because it was difficult for me to test projects with a history that I joined. I wanted autochecks to make sure my edit didn’t break anything.
But there was a developer in one project who, instead of covering legacy with autotests, wanted to “rewrite everything from scratch”. I really wanted to. I gave him a try to rewrite the piece from scratch. He released his edits and added non-critical site functionality. Everything that was rewritten went to the trash, because it was cheaper, faster and easier to return the old code. And on “controlled losses” I learned what a postmortem is. And as a kind of lesson, a person wrote autotests.
No error monitoring
Often startups have chats with early or active users. And now support or a product comes to you, says, “it doesn’t work for the user” (and then options: “I don’t know what”, “this is, but I don’t know the details”, and so on). If it works for you, go and find out what exactly and how does not work – hell. You get a cropped screenshot. Or just a repeat in the spirit of “still does not work, fix it URGENTLY” – for example, from the same user.
Until we connected the monitoring system, we found out that the site was lying with a delay of 10 minutes at best. From users. With monitoring, we finally began to fix bugs before they write to us. And as a bonus, critical bugs were opened more than once in the logs – for example, the fact that an order is created on the site, but is not saved to the database.
Instead of conclusions
You ask – so why are you eat cactus continue to work in the main startups?! I like to build processes out of chaos. During this time, I noticed that such projects have two troubles. There is no work with people. And there is no necessary automation. So there are two ways left. Educate people. And to implement time-tested tools and practices wherever possible: if everything is really bad, then start with organizing releases through CI \ CD. As part of this, you will have to agree on git and implement a code review. And all together will serve as a good basis for further improvements: organizing processes, setting up monitoring, and so on.
By going both ways, you will get a completely different level of development speed and quality. I usually go by myself such a scheme. If you want to discuss or supplement it in the comments, I will be glad and grateful. And of course, share your stories!
