YAGNI by the Book
I recently attended a workshop on Agile architecture by James Coplien. He made some very interesting remarks. He claims that your domain architecture,”what the system is”, is relatively stable. The domain of a bank or insurance company will not change that rapidly! Things that do change have to do with “what the system does”. The user stories and the user interface just to name two. He reasoned that you are creating “knowledge debt” if you know something but do not act upon it.
He further claims that doing too little architecture up front gets you into trouble around the third month of an agile project. To cope with new requirements and gained knowledge about the problem domain a lot of ‘refactoring’ or re-architecting as he calls it is needed. As a result your overall velocity goes down!
I personally experienced various projects that had to do excessive refactoring as sprints passed. The refactorings had a severe impact on velocity. In every one of these projects the misapplication of the Simple Design and YAGNI principle was part of the cause. The misapplication is in applying it to the letter. If you do that you are saying, “I focus only on what is valuable in the present and I assume I know nothing about the future because nothing is certain”.
The good thing is that you CAN know things about the future pretty accurately. There are always things you know upfront and that are relatively stable. “You know the sun will rise tomorrow”! It may not…. but I’ll bet you it will. If you are building a family car you know that it will require brakes. Putting in a steering wheel is not enough.
So if you apply YAGNI to the letter you are playing stoopid. You should use your knowledge about probable future things and act upon it. If this means putting in flexibility into the system this iteration because in the next you WILL need it, then just do it. I am not saying you should build functionality in the present it if it’s not part of the current iteration. I am just saying that you should always keep the design as good as it can be. Putting in flexibility for a highly probable feature in the near future sounds like good design to me!