How to deal with low or medium dev team level?

Question

In our team we have some low / medium level developers: they know how to write C#/JavaScript code, but most of it is an anemic domain model in a purely functionnal way of coding, but there are no unit tests, SOLID principles are not being respected, anti-patterns are a common practice, only the coding style conventions are respected. BUT the company is doing very fine, so we can say that what we are producing is fine as well.

Some part of the system are more than 10 years old, so with the time it's more and more becoming a spaghetti/lasagna code. The main code base is only 150k lines of code for 3-5 developers.

For making sure that we don't have to rewrite everything in 5 years, I'm trying to figure ou which way we should go. So I'm reading books/blogs ("Building Micro Services" by Sam Newman or "Patterns of Enterprise Application Architecture" by Martin Fowler for instance) and they are full of great patterns, but they all seems to need a developer level higher than what we have here.

Do you have any advice about what, as a technical director, I should try to improve our system quality without losing the entire team (and my CEO support) because I'm reviewing every single line of code?

For instance microservices seemed like a good thing but all the trouble with deployment, data synchronisation, and configuration seems to me like show stoppers.

Answer 1

Introduce good practices, one at a time. Maybe it is good to start with automated testing: adding regression tests in some cases and they go for unit testing for new code. This approach is taught in Working effectively with legacy code. Adding automated tests helps to adhere to SOLID principles, and also allows to refactor later to patterns.

Generally speaking, developers are always interested in doing the best if you show them how to do it. Maybe start spreading the good practices by showing how to do it. Introduce one good practice in a demo of 1 hour, and do it once a week. A suggestion, last thing on Wednesday so people can try the new practice on Thursday and Friday. Other day may work, but last thing on Friday is bad, people go to their homes, and do not discuss on how to implement at work.

Other hint, you don't own the code, the code is owned by the team. If you are the only reviewer puts pressure on you which should be on the team. So everybody should be engaged in understanding that quality is a must.

At last, do not re-write everything. This is a recipe for doom. Adding tests organically and then being able to replace parts of the software is better (because it is safer).

Answer 2

I'd like to second what pietromenna has said. One way that you could begin with automated testing is in terms of defect fixes. When your team encounters a defect, try to steer them in the direction of creating an automated test which simulates or exploits that defect before they create a fix for said defect. This will ensure that the defect will not occur again, and if it does, the team will know immediately so they have a better handle on fixing it. It's a good, immediate, way of demonstrating the power of the good practice that is automated testing.

Also, to again augment what pietromenna has said, I'd like to recommend the following: Refactoring to Patterns. A good understanding of the material in that book will not require developers at a higher level than what you have, regardless of their expertise.

Answer 3

Some advices:

• Don't get yourself overflown by the chore! (E.g. coding details)
• Do code reviews together with the team, help them in the beginning, later they can do it on their own.
• On new features do the planning with 1-2 of the skilled devs who know the background for the new fature.
• It is said that you should spend 80% of the time on the things where the income comes from. (Citation needed) You can start experimenting with the rest 20%: Make a microservice from an existing module, set up a continuous integration system for your team, etc.
• Automated tests +1
• You definitely need someone deep in DevOps.
• Maybe you have to learn the things that no one is capable of or willing to.
• You should build up the atmosphere of learning, "doing better". E.g. @pietromenna's suggestion of weekly demos, and you can send a few guys to Meetups or conferences as well.
• On the other hand: Don't go too far with the "hype bandwagons". There are many and they are fast. :)

Answer 4

Amazon uses a service-based architecture because it has a huge system, which it does rewrite (in a piece-meal fashion) every few years. In practice, most Amazon testers, programmers, project managers, and development managers are expected to make a significant contribution to a new service every year. This means that Amazon managers are constantly promoting "vapor-ware" ideas, in order to obtain funding and customers for new services. New services are typically designed to fill un-met needs, or replace multiple old services, or scale-up to much larger demands due to Amazon's growth.

My guess is that none of these reasons for adopting a micro-service architecture apply to your situation. Although 150,000 lines of code is large -- probably too large for one person to keep in their head -- it is small enough that one person could make changes throughout it over the course of a couple years.

My advice would be to make incremental improvements. Prioritize the improvements to get "quick wins" first, then repeatedly "go after" "low hanging fruit". Try to always make things "better than they were before". (This often requires being able to readily admit that a change hasn't helped, and be able to quickly and easily undo the change.)