YAGNI and junior developers

Question

When writing code for a new system I don't want to introduce unnecessary complexity in the design that I might never have any need for. So I'm following YAGNI here, and rather refactoring as I see the need for more flexibility or as responsibilities becomes more clear. This allows me to move faster.

But there is a problem here with junior devs, in that they will not recognize when to refactor or where build out the design. They just stuff more code into the existing design.

So, what are the best ways to tackle this? Should I more often build a more future-proof design so when adding to it they have a good example to follow, even if we might never have to add anything? Or should I just go ahead with more code reviews, education, etc? Or both?

Have any of you had any experience with this type of problem? How did you solve it?

Answer 1

There is a reason they are junior and you are senior.

The ability to realise when a change in design is needed is one of them.

I would carry on as you are but encourage them to come to you when things are getting difficult. You can then work with them to alter the design if needed, this will be easier for you than refactoring it and will help you pass on knowledge to your junior developers.

Answer 2

I would recommend code reviews or pair programming. It gives you the chance to educate your fellow developers and increase the overall quality.

Answer 3

A very good way to show how far to build out a design is to be specify about what the design will do when built out, then write tests to cover the new functionality. When the tests pass, development is done.

You might realize along the way that you forgot to test for something. That's fine, and is useful feedback to help you specify better next time. Write the missing test(s), and only enough code to make them pass.

Then refactor. Knowing what to look for when refactoring takes a bit of practice. Start with

• Is there duplication in the code we've just written that we can eliminate?
• Is there duplication between what we've just written and pre-existing code?
• Does the code we've just written concern itself with too many things? (I.e., should we break out collaborators?)

Repeat this a few dozen times, and it'll get easier.

Answer 4

I'm all for code reviews and teaching, but I think futureproof design is also important. Maybe you could think of it in terms of you designing an API and the junior developers using the API. In this way you are the one who does the hard work that they would screw up (identifying duplicated code and eliminating it) while they do all the grunt work that isn't a productive use of your time.

Of course this has to be balanced with a need to develop your junior developers skills. Neither side of the equation can be neglected.

Answer 5

Another way of looking at YAGNI is that any changes to code need to be justified.

Might it be helpful to require any commit needs an associated unit test (or BDD user story, choose your poison)? It helps to communicate your intent (you want people to think about why they are adding this feature) and you get regression tests for free.

Also gets the noobs to start thinking about modularity (usually needed to make your code testable) and will help a lot if you do need to refactor later on.

Answer 6

It may help to map out what work they will do and then verify it to help build their sense of judgement which is really what you are asking, to my mind. Pairing is one option but if you can't spare that much time then having a sort of "check point" to see how they are doing and preventing them from going down the wrong path.