In this post, I am going to talk about my personal opinion regarding DRY, KISS and YAGNI versus Coding Standards especially when working in a team setting.

I understand that you might not agree on some (or maybe even all) of the things that I have written here and I respect that. Everyone is entitled to their own opinion. So I encourage you all my readers, to look at this article with an objective perspective and a broader-than-usual mindset.

So with the disclosure out of the way, let me get to the point.

Always prioritize DRY, KISS and YAGNI over Coding Standards - even if you are in a team setting.

This comes with one condition however, that you need to have a good amount of test coverage so you have confidence in case that you need to refactor your code in the future.

DRY (Don't Repeat Yourself) - means that each small pieces of knowledge (code) may only occur exactly once in the entire system

KISS (Keep It Simple, Stupid!) - means to try to keep each small piece of software simple and unnecessary complexity should be avoided to not incur any technical debt.

YAGNI (You Ain't Gonna Need It!) - means that always implement things when you actually need them and never implement things before you need them.

I personally think these principles trump any coding standards a team might implement. And I am willing to go above and beyond that and say DRY, KISS and YAGNI should be the guiding principles of teams when implementing Coding Standards.

Story Time!

I have recently started working as a Lead Developer in a team, and one of their Coding Standard is to always use a FormRequest class in the controller.

So here I am, working on a feature and I have one endpoint that only receives one parameter on the request, which is already covered with written tests. Also, mind you that this request parameter is only used for this endpoint and not anywhere else in the application.

public function update(Request $request)
{
    $request->validate(['processed' => 'required|boolean' ]);

    // Some other process here then return a json response...
}

Now, I am being told to refactor this into a FormRequest class. So I asked, why? Because I honestly don't see the need to. Why do I have to incur additional tech debt by adding a separate class that will only be used for validating a single request attribute? And this piece is not going to be used in any other place,so i'm not violating code duplication. What gives? KISS and YAGNI!

But we have to follow Coding Standards!

This is a classic example of letting the developers incur additional techical debt without any benefit at all, just for the sake of Coding Standards. In my most honest opinion, when the code is well-tested, readable and at its simplest form; when it can be easily changed when the need arise, then that is a good code.

And I understand the need to be one with the team you are working with, but programming is not a military industry but a creative one. And the possible amount of incurred technical debt when blindly following coding standards far outweighs that argument. And most of the time, that incurred technical debt is never paid. I have seen it multiple times.

Also, developers grow when they get to figure out their ways of deciding when to use certain methodologies and tools, and when to keep things simple. That decision can then be guided by the team during a code review session. And again, as long as the code is covered with tests, refactoring should never be a big concern.