Looking To Hire More Developers? This One Is For You.

Let me tell you story.

There was a small software business developing a B2B cloud application.

At start, they had only 1 back-end and 1 front-end developer.

This was an already existing system they wanted to kinda update and refactor a little bit.

To speed things up and shorten the market delivery time, they scaled the team up and ended up with 3 back-end and 3 front-end developers.

The original system was built as a monolith.

Nothing wrong with monolith – I like them as long as they have a good design.

Now.

As you can imagine, hiring more developers to work on a system without documentation, with a bad design and without any rules to follow, resulted in a massive mess…

Developers couldn’t agree on how to style the code.

They also couldn’t agree on the code rules and everybody had their own idea.

Moreover, many developers have the mindset of looking for “the right” way.

Like there was only one and the only way…

This resulted in conflicts among team members which I witnessed with my own eyes…

Guys arguing about where the curly brace should be placed – on the same line vs. on a new line…

This story isn’t rare and these problems can be commonly found in many software companies.

So what’s the lesson of this story?

The first lesson is having processes set up BEFORE hiring or scaling up the team.

I always say if there’s a bad process – or no process at all – just randomness – you will get MORE CHAOS by scaling up.

In this company, there were no rules for the developers – no guidebook.

So when there was only one developer, there were basically no problems because he was his own boss.

He could choose the style, the rules, the whole way of creating the code.

Now imagine having 3 guys working with the same mindset – free for all – everybody on its own.

The conflict is inevitable.

My recommendation was to create a formal documented process for developers BEFORE hiring them.

Since the team was already hired, my advice was to ASAP create a guidebook for developers where the basic rules for the low-level development would be set.

In my view, small business is NOT a democracy – it’s a dictatorship.

If you ask 10 people on code rules – you’ll get MANY ideas – because everybody has their own idea – and their own preference.

This is definitely a NO WAY to make decision.

Somebody – the leadership – must make a decision and others will have to suck it.

So by taking look at the code and after discussions with the developers, we created this “guidebook” for developers – to which each developer had to adhere.

You can bet the developers were NOT happy about suddenly having a rule book that told them what rules to follow.

But hey! It’s their job. They are employed and if they wanna be a part of the company, and are assigned to a team project, they will have to follow team-wide rules.

This guidebook contained basic MANDATORY RULES for each developer working on the code.

The rules ARE MANDATORY and violations are taken care of.

The important part of this is that the rules MUST BE ENFORCED, otherwise the team will quickly realize nobody’s checking that and they resort to doing things however they like.

The point of this guidebook is to establish FOUNDATIONAL rules for the code.

What to do and what NOT to do.

How to name tables, objects, interfaces, endpoints, etc.

How to handle more complex cases – what has to be done when you want to remove a column for the database, etc.

This guidebook enforced basic rules for the code so that things could nicely work together.

Guidebook rules = mandatory & enforced.

Anything outside of the rules = you have a free hand and can choose your own solutions.

New important cases = update the guidebook.

As you can image, after having this guidebook in place, the code-base quality started to become better and better every single day, because the developers KNEW how to do certain things in way that their work would be compatible.

The guidebook also contained rules for what NOT TO DO because these ways would break the API compatibility with the front-end.

As for the arguments.

Most of them stopped because things started to become compatible – the guidebook introduced a PROCESS for having one developer’s code being compatible with other developer’s code.

This guidebook is especially important for JUNIOR developers who need guidance.

If you’re familiar with software architectures, you might think about having the system split into micro-service architecture, so that each developer has kinda his own space where he applies his own rules.

I don’t wanna go too deep into micro-services here, but my advice was to STICK with the monolith architecture for several reasons.

One of the reasons was that I wanted the leadership to focus on the SOURCE of the problem = lacking processes and clear guidelines for their team, instead of trying to get around it by changing the architecture of the whole system.

It’s like bringing in bulldozers to demolish the whole hotel because you know, the kitchen team has hard times making meals of consistent quality.

Fix the freakin’ problem, keep the hotel standing.

Our problem in this case was the lacking process.

So if you plan to expand your team, make sure you have processes defined – otherwise you risk scaling up chaos.

If you wanna discuss processes, team issues or conflicts during development, apply for a free call or shoot me a message and we’ll take it from there…