Xjyuk

As the sole developer in a startup, I had the luxury of being able to make a lot of decisions in the architecture and frameworks of our application.

Fast forward 4 years and an acquisition later, I have a team of 5 and a lot of times it feels like the wild west. People making whatever design decision pleases them: integer and enums for DB types in one place and string another, this framework for a problem and then a different framework for the same problem elsewhere, etc.

How do I go about enforcing consistency? It feels important to me but my team members seem to subscribe to the "if it works, it works" methodology.

I guess a big part of my question is: is it unrealistic of me to expect standards like this? I struggle with the idea of coming across as a dictator that stifles creativity but doing whatever they want seems to not be scalable.

What makes you so special?

My CPU says it works and I want to go home. Why are you bothering me?

You can deal with this attitude by forcing everyone to issue pull requests. But now the deadlines are looming. Bad code presses on the gates of your pristine castle and you finally give in to the pressure. Or you win only to find everyone leaves and no one uses your pristine castle.

There are plenty of tools that help with this issue. Source control, code reviews, etc. but the heart and soul of the problem is your subjective opinions about what is best have to be seen as relevant. For that you have to earn and maintain their respect. Do that and this is much easier. Fail to do that and no tool or practice will save you.

The best way to do that is communicate early. Don't tell me "we don't use strings for our DB types in this shop" 6 months after I settled on the idea. Telling me it's been buried in the documentation for 2 years is no justification for letting me do that.

For whatever reason you have things you care about. If you care about them and have a point get those things communicated clearly before, during, and after the coding of every module.

Code stalking is a wonderful practice. Invest in whatever tools and practices you need so you can review code within minutes of it being written. Pair program and the tool is simply a guest chair.

Why? Every second that passes after I write code exponentially increases the cost to change it. That's because my memory of the code has a half life. I start forgetting it the moment my bladder demands a break.

Reduce the things you care about to their underlying principles. Rather then hit me with a list of 101 rules to follow give me the 10 principles that they all violate so I can figure out what rule 102 should be on my own.

Empower me to impose my own vision by helping me see yours and we'll get along great.

is it unrealistic of me to expect standards like this? I struggle with the idea of coming across as a dictator that stifles creativity but doing whatever they want seems to not be scalable.

Then don't dictate! Make this a positive experience. This isn't some new age hippy nonsense. It's basic psychology. You are trying to modify behavior. Random and positive Is the most reinforcing. If you go negative you have to be consistent with your reinforcement. Thats an unobtainable pain. Be positive as you spread the wisdom and you can be casual about it.

First, get people to maintain things they didn't write. It's very easy for a developer to get into habits of using frameworks and techniques they are used to. It's jarring to have to switch between frameworks and methodologies. If someone is forced to move outside of their own corner of the code and experience that often, it will prompt some complaining and hopefully some productive discussion that can lead to people wanting to standardize on something.

Next, pull requests and code reviews. Never allow code to be merged to your main branches without a code review first. Anyone can do it. Again, when someone sees something that's different than what they would have done, it can prompt discussion and teamwork to come to a better solution. It also makes everyone a caretaker of the code base, which (hopefully) gets people to care about it and the state of the code that goes into it.

Finally, have design discussions. They can be formal or informal, but have them. Let those that want to participate do so. Discuss what frameworks you want to use, the pros and cons of enums vs ints, etc. Then come to a decision and document it somewhere (like a standards document). Then you have something to point to when problems arise. Also, don't be afraid to revisit a standards decision. Technology changes (quickly) and so can your needs as a team and as a company.

Help people to see what you see and feel like they have a stake in the quality of the code. Then gently prod discussions towards finding a standard when differences of opinion come up.

Perform code reviews every time someone wants to merge code into the main branch/trunk and hold people to those standards when reviewing the code.

And I don't mean that only you should perform the code reviews. Everyone should review everyone else's code. This disseminates knowledge about the system across the team but also creates a situation where Carol reviews Bob's code and says, "I see you used an integer there. I always use an enum." They discover the discrepancies that you've seen and, assuming they care, they will realize that everyone's got to get on the same page.

The accepted, agreed-upon standards will emerge, at which point you document them and make sure people follow them. This would include things like "enums in the DB for ...", etc. You can also include documenting which frameworks to use, etc.