Are KISS and YAGNI at odds with the trends towards increasingly more sophisticated patterns and practices like SOA, DDD, IoC, MVC, POCO, MVVM?

Question

It seems to me that Agile methodologies encourage us to keep things simple, and lean, and not add complexity and sophistication until its needed. But the pace and volume of technology change encourages the use of increasingly abstract, complex and sophisticated tools and patterns to solve problems that we may not have yet (and may never encounter) in complex ways with significant learning curves and significant investments of effort.

Answer 1

Its a matter of the right tool for the right job. The problem is when architects and/or developers begin to believe that a particular methodology or technology is a "golden hammer." That is when things become religious, and religion and reason do not play nicely together ;)

Oh and by the way, "agile" does not necessarily mean you don't use some of the acronyms you mention, or some framework that implements them. Those decisions are usually made far in advance of implementing the sorts of things that developers have come to associate with agile, e.g. user stories, sprints, etc.

Answer 2

I'll keep my answer short and let the experts lay it out better...

I think that KISS applies to everything you listed. You mention increasing abstraction and complexity, which, I think, balance eachother.

The systems we are developing today must be complex, because, most of the time, the solution to a complex problem is inherently complex. However, to keep things simple, we use abstraction. Even if our complex system is built with, say, eight layers, we can follow KISS by keeping each layer simple.

For instance, to pick an item or two off your list:

• SOA is not complex because we can wrap service calls in a wrapper object. This object handles the connection and makes calls, which are pretty easy to do because they simply pass parameters on.
• MVC is not complex because we clearly separate our logic. We have a simple controller for directing requests and setting up data, a simple model to represent our domain, and a simple view that displays whatever data is passed to it.

However, in both of these cases, the pattern as a whole (or the system, if you will) is complex and non-trivial. It is the fact that we consider small, simple parts one at a time, and then fit them together, that lets us maintain our mental model as we work.

Answer 3

Are KISS and YAGNI at odds with the trends towards increasingly more sophisticated ...

A car has an accelator and a brake, and a steering wheel that can turn left and/or right: it's up to the drivers to decide which to use when.

Answer 4

I'm going to make a subjective answer (so sue me). I think that if you program by acronyms then you are going to run into trouble.

At the end of the day you are trying to make money for a business, or hopefully yourself. As such each decision you make is an engineering decision based on cost, time and benefits. You have to evaluate the use of a technique on the cost of implementation, maintenance etc, and make the best choice.

I think the only fair answer is that the tools and techniques chosen have to match with the desired goal of the engineering.

Answer 5

First off, the list of acronyms doesn't really necessarily make sense - there's not really much simpler than POCO, for example...

However, KISS and YAGNI are achieved most effectively, in many circumstances, by using concepts like IoC, MVC, and MVVM - provided you use the patterns correctly.

Patterns aren't complicated, in and of themselves. It may take a bit of learning to understand what the pattern is trying to accomplish, but often, a pattern exists purely to simplify either code, maintenance, or usability - and usually all of the above. This fits in perfectly with keep it simple, for example.

Answer 6

yes

-- this space intentionally left blank --

Answer 7

IMHO, you (generally) don't want to start out with a complicated design. Could this be a local method rather than a service? Do I need an IoC container yet? This is particularly relevant when it comes to design patterns.

However, as you test and refactor your code, certain patterns (such as Ioc) will help you to achieve goals such as testability and DRY (Don't Repeat Yourself). If you know design patterns well, you can apply them at the appropriate time.

Answer 8

I agree with ChrisW's answer.

The idea is to stick with KISS and YAGNI as much as possible, but when the need arises and you need a sophisticated / complex solution, stand on the shoulders of giants and use proven patterns to guide you. These patterns and practices are meant to simplify your work, if using them is harder than the hack alternative, you should stick with the hack. Just make sure you take into account maintainability etc.

As an example, when you build the 1st version of a website it may consist of 1 or 2 main functionalities and just a few pages. You probably don't need MVC for this (even though it might be nice to start that way) BUT, after you add a few more features and you have dozens of pages to manage along with how to share functionality between them, it might become apparent that you need MVC to better structure your application.

Similarly, if from the get go you know you will have to deal with something like returning multiple views of a common piece of data, MVC simplifies your problem by laying out a pattern for you to follow.

In summary, YAGNI now, but if you need it later then KISS by using a known pattern / solution.

Answer 9

Sigh.

We must have increasingly sophisticated and abstract components to match the demand for increasingly sophisticated software.

Most of us have limited brain space. We must learn to cope with our limited brains by using more sophisticated abstractions.

The alternative is not using abstractions, limiting ourselves to machine code.

Please read http://www.cs.utexas.edu/~EWD/transcriptions/EWD01xx/EWD117.html

"In spite of all its deficiencies, mathematical reasoning presents an outstanding model of how to grasp extremely complicated structures with a brain of limited capacity. And it seems worthwhile to investigate to what extent these proven methods can be transplanted to the art of computer usage. In the design of programming languages one can let oneself be guided primarily by considering "what the machine can do". Considering, however, that the programming language is the bridge between the user and the machine --that it can, in fact, be regarded as his tool-- it seems just as important to take into consideration "what Man can think". It is in this vein that we shall continue our investigations."