TDD, Scrum and architecture: KISS and complexity conflict

Question

I work now since one year following Scrum, TDD, Domain Driven Design and Uncle Bob's recipes.. but I have some doubt about are we applying the various principles, mostly while reading "Java Application Architecture" (from now JAA) always from Martin's series. Please correct me if I'm wrong! (and hopefully I am) The problem start with TDD and Scrum stating that we should evolve the system implementing the requirements once they appear, avoiding upfront design. This make me work leaving all extensibility points open, (ab)using all kind of extensibility patterns all times. This has indeed a "dark side": adding complexity to the whole system. I don't know in advance if a certain part of my code would need to evolve further.

BUT, as correctly stated everywhere (and really often on JAA) you should add complexity only when needed. This IMHO carries to the conclusion that a decent up-front analysis should be made... conflicting with the rest of recipes...

Therefore the loop.... aaargh i hate circular dependencies!!!

Should we refactor things to reduce complexity after a feature is "confirmed"? Should we use the simplest way allowed and only if needed expand it? e.g. don't build super decoupled things when you don't need them yet?

(Any suggestion to improve the question style and content is welcome, i'm a newbie on stackoverflow)

Answer 1

Should we refactor things to reduce complexity after a feature is "confirmed"? Should we use the simplest way allowed and only if needed expand it? e.g. don't build super decoupled things when you don't need them yet?

Yes. Although this is rather subjective, I dislike systems that have the flexibility to change every single thing there is to change, while you will not utilise all of those flexibilities. Your statement is contradictory though: Test Driven Development has taught me to "do the simplest thing that could possibly work".

If more functionality is needed, you can add tests, and then refactor and extend the code to make sure it does the thing you want it to do. Because you have tests in place, you can rest assured you won't break the currently existing code.

In short: don't build flexibility because you can. You should build flexibility because the situation dictates you to. I firmly believe that refactoring "on demand" makes the build time of your project shorter than having (unused) flexibility built in. With your tests in place, the refactoring "on demand" shouldn't take too long.

Shorter still: Keep It Simple, Stupid. ;)