Take the 2-minute tour ×

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.

share|improve this question
Today we live in an ARE (Acronym rich environment) –  Spence Sep 10 '09 at 1:42
Was there a question in there? –  Yishai Sep 10 '09 at 1:44
wtf? afaict, i need a dictionary to decode tfq asap ftw. brb –  Wouter van Nifterick Sep 10 '09 at 1:50
How did POCO sneak into that list? :) –  JoshJordan Sep 10 '09 at 1:52
No, common sense "encourage[s] us to keep things simple, and lean, and not add complexity and sophistication until it[']s needed", not Agile. Geez, do Agile people want to claim credit for everything? –  MusiGenesis Sep 10 '09 at 2:32
show 3 more comments

closed as not a real question by Wouter van Nifterick, Reed Copsey, Robert Cartaino, Steven A. Lowe, Stu Thompson Sep 10 '09 at 5:05


9 Answers

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.

share|improve this answer
That, sir, is an excellent analogy. –  Chris Lutz Sep 10 '09 at 1:56
It's hard to get all indignant about there being choices and guidelines. Normally when people complain it's about having only one 'paradigm' and mis-using it: the "when all you have is a hammer, everything looks like a nail" quote. –  ChrisW Sep 10 '09 at 2:09
When your only hammer is C++, everything looks like a thumb ;) –  George Jempty Sep 10 '09 at 12:38
add comment

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.

share|improve this answer
KISS applies not just to the simplicity of each part, but also to the total number of parts. –  MusiGenesis Sep 10 '09 at 2:33
Guess that depends on how you think about it. –  JoshJordan Sep 10 '09 at 2:43
add comment

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.

share|improve this answer
add comment


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

share|improve this answer
+1 - Well said! –  JoshJordan Sep 10 '09 at 2:55
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment


-- this space intentionally left blank --

share|improve this answer
-- this comment intentionally left blank -- –  LiraNuna Sep 10 '09 at 2:12
This post intentionally voted down. –  JoshJordan Sep 10 '09 at 2:20
add comment
