What should take precedence: YAGNI or Good Design?

Question

At which point should YAGNI take precedence against good coding practices and vice versa? I'm working on a project at work and want to slowly introduce good code standards to my co-workers (currently there are none and everything is just kind of hacked together without rhyme or reason), but after creating a series of classes (we don't do TDD, or sadly any kind of unit testing at all) I took a step back and thought it's violating YAGNI because I pretty much know with certainty that we don't require the need to extend some of these classes.

Here's a concrete example of what I mean: I have a data access layer wrapping a set of stored procedures, which uses a rudimentary Repository-style pattern with basic CRUD functions. Since there are a handful of methods that all my repository classes need, I created a generic interface for my repositories, called IRepository. However, I then created a "marker" interface (i.e. interface that doesn't add any new functionality) for each type of repository (e.g. ICustomerRepository) and the concrete class implements that. I've done the same thing with a Factory implementation to build the business objects from DataReaders/DataSets returned by the Stored Procedure; the signature of my repository class tends to look something like this:

public class CustomerRepository : ICustomerRepository
{
    ICustomerFactory factory = null;

    public CustomerRepository() : this(new CustomerFactory() { }

    public CustomerRepository(ICustomerFactory factory) {
        this.factory = factory;
    }      

    public Customer Find(int customerID)
    {
        // data access stuff here
        return factory.Build(ds.Tables[0].Rows[0]);
    }
}

My concern here is that I'm violating YAGNI because I know with 99% certainty that there is never going to be a reason to give anything other than a concrete CustomerFactory to this repository; since we don't have unit tests I don't need a MockCustomerFactory or similar things, and having so many interfaces might confuse my co-workers. On the other hand, using a concrete implementation of the factory seems like a design smell.

Is there a good way to come to a compromise between proper software design and not overarchitecting the solution? I'm questioning if I need to have all of the "single implemenation interfaces" or if I could sacrifice a bit of good design and just have, for example, the base interface and then the single concrete, and not worry about programming to the interface if the implementation is that will ever be used.

Answer 1

Is there a good way to come to a compromise between proper software design and not overarchitecting the solution?

YAGNI.

I could sacrifice a bit of good design

False assumption.

and the base interface and then the single concrete,

That's not a "sacrifice". That is good design.

Answer 2

In most cases, avoiding code that you aren't going to need leads to better design. The most maintainable and future-proof design is the one that uses the smallest amount of well-named, simple code that satisfies the requirements.

The most simple designs are the most easy to evolve. Nothing kills maintainability like useless, overengineered abstraction layers.

Answer 3

YAGNI and SOLID (or any other design methodology) are not mutually exclusive. However, they are near-polar opposites. You do not have to adhere 100% to either, but there will be some give-and-take; the more you look at a highly-abstracted pattern used by one class in one place, and say YAGNI and simplify it, the less SOLID the design becomes. The reverse can be true as well; many times in development, a design is implemented SOLIDly "on faith"; you don't see how you will need it, but you just have a hunch. This could be true (and is more and more likely to be true the more experience you gain), but it could also put you in as much technical debt as a slap-dash "do it light" approach; instead of a DIL "spaghetti code" codebase, you may end up with "baklava code", having so many layers that simply adding a method or a new data field becomes a days-long process of wading through service proxys and loosely-coupled dependencies with only one implementation. Or you could end up with "spaghetti-Os code", which comes in such small, loosely-structured pieces that moving up, down, left or right in the architecture takes you through 50 methods with 3 lines each.

I've said it in other answers, but here it is: On the first pass, make it work. On the second pass, make it elegant. On the third pass, make it SOLID.

Breaking that down:

When you first write a line of code, it simply has to work. At this point, for all you know, it's a one-off. So, you don't get any style points for building an "ivory-tower" architecture to add 2 and 2. Do what you gotta do, and assume you'll never see it again.

The next time your cursor goes in that line of code, you have now disproved your hypothesis from when you first wrote it. You are revisiting that code, likely either to extend it or to use it elsewhere, so it's not a one-off. Now, some basic principles like DRY (don't repeat yourself) and other simple rules for code design should be implemented; extract methods and/or form loops for repeated code, extract variables for common literals or expressions, maybe add some comments, but overall your code should self-document. Now, your code is well-organized, if still maybe tightly-coupled, and anyone else looking at it can easily learn what you're doing by reading the code, instead of tracing it line-by-line.

The third time your cursor enters that code, it's probably kind of a big deal; you're either extending it yet again or it's become useful in at least three different other places in the codebase. At this point, it's a key, if not core, element of your system, and should be architected as such. At this point, you usually also have the knowledge of how it's been used so far, which will allow you to make good design decisions regarding how to architect the design to streamline those usages and any new ones. Now the SOLID rules should enter the equation; extract classes containing code with specific purposes, define common interfaces for any classes that have similar purposes or functionality, set up loosely-coupled dependencies between classes, and design the dependencies such that you can easily add, remove, or swap them.

From this point on, should you need to further extend, reimplement or re-use this code, it's all nicely packaged up and abstracted in the "black box" format we all know and love; plug it in wherever else you need it, or add a new variation on the theme as a new implementation of the interface without having to change the usage of said interface.

Answer 4

Instead of either of those, I prefer WTSTWCDTUAWCROT?

(What's the simplest thing we can do that's useful and we can release on Thursday?)

Simpler acronyms are on my list of things to do, but they're not a priority.

Answer 5

YAGNI and good design are not conflicting. YAGNI is about (not) supporting future needs. Good design is about making transparent what your software does right now and how it does this.

Will introducing a factory make your existing code simpler? If not, don't add it. If it does, for example when you are adding tests (which you should do!), add it.

YAGNI is about not adding complexity to support future functions.
Good Design is about removing complexity while still supporting all current functions.

Answer 6

They aren't in conflict, your goals are wrong.

What are you attempting to accomplish?

You want to write quality software, and to do that you want to keep your code base small and not have issues.

Now we reach a conflict, how do we cover off all cases if we don't write cases we aren't going to use?

Here's what your problem looks like.

(anyone interested, this is called evaporating clouds)

So, what's driving this?

1. You don't know what you're not going to need
2. You don't want to waste time and bloat your code

Which one of these can we solve? Well, it looks like not wanting to waste time and bloat code is a great goal, and makes sense. What about that first one? Can we find out what we're going to need to code?

I'm working on a project at work and want to slowly introduce good code standards to my co-workers (currently there are none and everything is just kind of hacked together without rhyme or reason) [...] I took a step back and thought it's violating YAGNI because I pretty much know with certainty that we don't require the need to extend some of these classes.

Let's re-phrase all of that

• No code standards
• No project planning going on
• Cowboys everywhere doing their own damn thing (and you're trying to play sheriff in the wild wild west), yee haw.

Is there a good way to come to a compromise between proper software design and not overarchitecting the solution?

You don't need a compromise, you need someone to manage the team who is competent and has vision of the whole project. You need someone who can plan what you ARE going to need, instead of each of you throwing in things you ARE NOT going to need because you're so uncertain of the future because... why? I'll tell you why, it's because nobody has a damn plan among all of you. You're trying to bring in code standards to fix an entirely separate issue. Your PRIMARY problem you need to solve is a clear roadmap and project. Once you have that, you can say "code standards help us reach this goal more effectively as a team," which is the absolute truth but outside the scope of this question.

Get a project/team manager who can do these things. If you have one, you need to ask them for a map and explain the YAGNI problem that not having a map is presenting. If they're grossly incompetent, write the plan yourself and say "here's my report for you on things we need, please review it and let us know your decision."

Answer 7

Allowing your code to be extended with unit tests is never going to be covered under YAGNI, because you will need it. However, I'm not convinced that your design changes to a single-implementation interface are actually increasing the testability of the code because CustomerFactory already inherits from an interface and can be swapped out for a MockCustomerFactory at any time anyway.

Answer 8

The question presents a false dilemma. Proper application of the YAGNI principle isn't some unrelated thing. It's one aspect of good design. Each of the SOLID principles are aspects of good design as well. You can't always fully apply every principle in any discipline. Real-world problems put a lot of forces on your code, and some of those push in opposing directions. Principles of design have to account for all of those, but no handful of principles can fit all situations.

Now, let's take a look at each principle with the understanding that while they may sometimes pull in different directions, they are by no means inherently in conflict.

YAGNI was conceived to help developers avoid a particular kind of rework: that which comes from building the wrong thing. It does this by guiding us to avoid making errant decisions too early based on assumptions or predictions about what we think will change or be needed in the future. Collective experience tells us that when we do this, we are usually wrong. For example, YAGNI would tell you not to create an interface for the purpose of reusability, unless you know right now that you need multiple implementers. Similarly YAGNI would say don't create a "ScreenManager" to manage the single form in an application unless you know right now that you're going to have more than one screen.

Contrary to what many people think, SOLID is not about reusability, genericity, or even abstraction. SOLID is intended to help you write code that is prepared for change, without saying anything about what that specific change might be. The five principles of SOLID create a strategy for building code that is flexible without being overly generic, and simple without being naive. Proper application of SOLID code produces small, focused classes with well-defined roles and boundaries. The practical result is that for any needed requirements change, a minimum number of classes need to be touched. And similarly, for any code change, there is a minimized amount of "ripple" through to other classes.

Looking at the example situation you have, let's see what YAGNI and SOLID might have to say. You are considering a common repository interface due to the fact that all the repositories look the same from the outside. But the value of a common, generic interface is the ability to use any of the implementers without needing to know which one it is in particular. Unless there is somewhere in your app where this would be necessary or useful, YAGNI says don't do it.

There are 5 SOLID principles to look at. S is Single Responsibility. This says nothing about the interface, but it might say something about your concrete classes. It could be argued that handling the data access itself might best be made a responsibility of one or more other classes, while the repositories' responsibility is to translate from an implicit context (CustomerRepository is a repository implicitly for Customer entities) into explicit calls to the generalized data access API specifying the Customer entity type.

O is Open-Closed. This is mostly about inheritance. It would apply if you were trying to derive your repositories from a common base implementing common functionality, or if you expected to derive further from the different repositories. But you're not, so it doesn't.

L is Liskov Substitutability. This applies if you intended to use the repositories through the common repository interface. It places restrictions on the interface and implementations to ensure consistency and avoid special handling for different impelementers. The reason for this is that such special handling undermines the purpose of an interface. It might be useful to consider this principle, because it may warn you away from using the common repository interface. This coincides with YAGNI's guidance.

I is Interface Segregation. This may apply if you start to add different query operations to your repositories. Interface segregation applies where you can divide the members of a class into two subsets where one will be used by certain consumers and the other by others, but no consumer will likely use both subsets. The guidance is to create two separate interfaces, rather than one common one. In your case, it's unlikely that fetching and saving individual instances would be consumed by the same code that would do general querying, so it might be useful to separate those into two interfaces.

D is Dependency Injection. Here we come back to the same point as the S. If you separated your consumption of the data access API into a separate object, this principle says that rather than just newing up an instance of that object, you should pass it in when you create a repository. This makes it easier to control the lifetime of the data access component, opening up the possibility of sharing references to it between your repositories, without having to go the route of making it a singleton.

It's important to note that most of the SOLID principles don't necessarily apply at this particular stage of your app's development. For example, whether you should break out data access depends on how complicated it is, and whether you want to test your repository logic without hitting the database. It sounds like this is unlikely (unfortunately, in my opinion), so it's probably not necessary.

So after all that consideration, we find that YAGNI and SOLID actually do provide one common piece of solid, immediately-relevant advice: It's probably not necessary to create a common generic repository interface.

All this careful thought is extremely useful as a learning exercise. It's time consuming as you learn, but over time you develop intuition and becomes very quick. You'll know the right thing to do, but don't need to think all these words unless someone asks you to explain why.

Answer 9

You seem to believe that 'good design' means following some sort of idealogy and formal set of rules that must always be applied, even when useless.

IMO that's bad design. YAGNI is a component of good design, never a contradiction to it.

Answer 10

In your example, I would say that YAGNI should prevail. It won't cost you that much if you need to add interfaces later. By the way, is it really good design to have one interface by class if it serves no goal at all ?

One more thought, maybe sometimes what you need is not Good Design but Sufficient Design. Here are is very interesting sequence of posts on the topic :

• Sufficient Design
• Sufficient Design Means Damned Good Design
• When Sufficient Design means Poor Design

Answer 11

Some people argue, that interface names should not be starting with I. Specifically one reason is, that you're actually leaking the dependency on whether the given type is a class or an interface.

What prohibits you from CustomerFactory being a class at first and later changing it into an interface, that will either be implemented by DefaultCustormerFactory or UberMegaHappyCustomerPowerFactory3000? The only thing you should be having to change is the place, where the implementation gets instantiates. And if you have a more less good design, then this is a handful of places at most.

Refactoring is a part of development. Better have little code, that is easy to refactor, than have an interface and a class declared for every single class, forcing you to change every method name in at least two places at the same time.

The real point in using interfaces is achieving modularity, which is possibly the most important pillar of good design. Note however, that a module is not only defined by its decoupling from the outside world (even though that is how we perceive it from the outside perspective), but equally by its inner working.
What I mean to point out is, that decoupling things, that inherently belong together doesn't make much sense. In a way it is like having a cupboard with an individual shelf per cup.

The importance lies in devising a big, complex problem into smaller, simpler subproblems. And you must stop at the point, where they become simple enough without further subdivisions, or else they will in fact become more complicated. This could be seen as a corollary of YAGNI. And it definitely means good design.

The goal is not to somehow solve a local problem with a single repository and a single factory. The goal is, that this decision has no effect on the rest of your application. That's what modularity is about.
You want your coworkers to look at your module, see a facade with a handful of self-explanatory calls and feel confident, that they can use them, without having to worry about all the potentially sophisticated inner plumbings.

Answer 12

You're creating an interface anticipating multiple implementations in the future. You might as well have an I<class> for every class in your codebase. Don't.

Just use the single concrete class according to YAGNI. If you find you need to have a "mock" object for testing purposes, turn the original class into an abstract class with two implementations, one with the original concrete class and the other with the mock implementation.

You will obviously have to update all the instantiations of the original class to instantiate the new concrete class. You can get around that by using a static constructor up front.

YAGNI says not to write code before it needs to be written.

Good design says to use abstraction.

You can have both. A class is an abstraction.

Answer 13

Why the marker interfaces? It strikes me that it's doing nothing more than "tagging". With a different "tag" for every factory-type, what's the point?

The purpose of an interface is to give a class "acts like" behavior, to give them "repository-ability" so to speak. So if all your concrete repository-types behave like the same IRepository (they all implement IRepository) then they all can be handled in the same way by other code - by the exact same code. At this point your design is extensible. Adding more concrete repository-types, all handled as generic IRepository(ies) - the same code handles all concrete types as "generic" repositories.

Interfaces are for handling things based on commonalities. But custom marker interfaces a) add no behavior. and b) force you to handle their uniqueness.

To the extent you design useful interfaces you get the OO goodness of not having to write specialized code to handle specialized classes, types, or custom marker interfaces that have a 1:1 correlation to concrete classes. That's pointless redundancy.

Off hand I can see a marker interface if, for example, you needed a strongly typed collection of lots of different classes. In the collection they are all "ImarkerInterface"s but as you pull them out you're having to cast them to their proper types.

Answer 14

Can you, right now, write down a vaguely reasonable ICustomerRepository? E.g., (really reaching here, probably a bad example) in the past your customers have always used PayPal? Or everybody in the company is abuzz about hooking up with Alibaba? If so, you might want to use the more complex design now, and appear farsighted to your bosses. :-)

Otherwise, wait. Guessing at a interface before you have one or two actual implementations usually fails. In other words, don't generalize / abstract / use a fancy design pattern until you have a couple of examples to generalize.