I’m not sure if this is a trap, but I find myself doing this more and more. Let’s say you have a short (less than 2 weeks) project to work on, and maybe it’s for a church website or something similar. Non-business critical, but the customer wants it to look nice, wants it simple, and doesn’t want to pay much (or anything) for it.
You have two choices for the application architecture. One is the Evans’ style, the “new default architecture” that has a nice layered approach to it. The other is to use lots of WYSIWYG designer tools, such as LINQ to SQL, that can get you up and running quickly.
What I tend to do is opt for the more complex architecture first, even though the customer explicitly doesn’t need it. YAGNI tells me that I should opt for the cheaper architecture, and add complexity when required. Pragmatism tells me that it’s difficult to switch the entire architecture of an application. It’s difficult to switch from designer-based infrastructure to something more robust like NHibernate.
To make it easy to move away from LINQ to SQL, I’d need to abstract away my interactions with that library so I can switch it out for something else. The problem is that it’s just as much work to implement a layered approach as it is to try an abstract away LINQ to SQL.
And this is my dilemma: By locking myself in to a less flexible technology, I’ve limited the future complexity my solution can handle. Even though LINQ to SQL is great for forms-over-data, I can’t predict what my church website might need in the future. Since customer’s needs always change, how can I guess about future complexity?
I don’t really know if my customer will need more complexity in the future, but I assume they will. If the customer needs more complexity, and the architecture can’t handle it, I’m stuck re-writing significant portions of the application to use NHibernate instead.
Even though NHibernate isn’t always the simplest thing that could possibly work, I find myself opting to use it first as I know it can handle future complexity much better than the alternatives.