0

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.

kayess
  • 241
remi bourgarel
  • 147
  • How good are you in architeture and devops? – Gábor Imre Jun 07 '17 at 12:38
  • 3
    You see, for what I could grasp from your question, you too seem to be lacking a bit on architecture design and software development overall. Microservices aren't a silver bullet and you can't really just pick and choose patterns. Martin Fowler's material has some nice guidelines, but they aren't intended as absolute rules and should be taken with a grain of salt and a lot of care. It's easy to interpret his work as "the one right true way" of doing things, but "right" in software development always depends on your context and you always can do the same thing in several different ways. – T. Sar Jun 07 '17 at 13:10
  • So, maybe you should jump in into the software development first, with them instead of trying to guide a team with lacking knowledge about what they are doing and why. – T. Sar Jun 07 '17 at 13:11
  • 2
    I would strongly debate your statement that "what we are producing is fine". Based on what you have said, it's far more likely that it's riddled with as-yet-undiscovered problems and technical debt that you simply haven't had to pay yet. – Paul Jun 07 '17 at 13:15
  • @Paul, what if the company succeed during the next 10 years, you will admit you're wrong ? I don't think every succeeding company have a low technical debt. – remi bourgarel Jun 07 '17 at 13:28
  • 1
    See also How to decide whether to adopt a micro-services approach? – Jasper Jun 19 '17 at 17:32

4 Answers4

6

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).

pietromenna
  • 1,148
  • 1
    Interesting. The problem with automating testing is the learning curve that implies a drop in productivity, but indeed it's a good start for writing better code. And you're absolutly right : I have to be more with them (like a day every month on pair programming) and we will never rewrite from scratch, like ever. – remi bourgarel Jun 07 '17 at 13:31
  • @remibourgarel You should be pair programming a couple of hours every day, if you want to truly grasp your team. – T. Sar Jun 07 '17 at 13:38
  • @Tsar don't you think they could think they are not trusted ? Maybe if I show this as an ambitious project and I'll accompany them. – remi bourgarel Jun 07 '17 at 14:02
  • If you want to improve your team you'll definitely lose some productivity. You need some diplomatic skills to sell this to the CEO. So keep bringing nice visible results besides improving the team. – Gábor Imre Jun 07 '17 at 14:04
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.

Langecrew
  • 142
1

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. :)
Gábor Imre
  • 185
0

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.)

Jasper
  • 119
  • 1
    Micro services seems interesting mainly for 2 reason : in term of business it's very nice to be able to have a lot of decoupled component and being able to integrate them with external system easily, and for a new comer in the compagny, it might afraid them less when they see only small project instead of a big solution with 150k LOC. But w don't have the technical level required for this kind of architecture so we'll try to improve the existing solution (just like you suggest), and maybe on new project think about new servcies. – remi bourgarel Jun 19 '17 at 15:40