Best tool for the job

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.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile, Tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • If you consider the first implementation with all its drag-n-dropness to be a prototype, then I could see going this way. In fact, I did go this way for a church web site. I explained up front the trade-offs, and I push back on any requirements that don’t go within the current framework. It may get rewritten at some point, but that’s a compromise that everyone was willing to make.

  • I understand the difficulty, but a question you need to consider is, ‘who will be maintaining the application’. If you know there’ll be someone around who is willing/able to deal with the complexity then adding it in the beginning only (negatively) effects your initial effort. If you can’t be certain the skills of future developers you may be adding non-functional complexity. The simple/cheaper solution may not be the best choice for responding to change, but the chances are it will be easier for them to find development resources in the future with a ‘standard’ solution. Sad, but often true in my experience.

  • I’m actually building v2.0 of my church’s website right now and I opted to go with Rails as I thought it was a nice balance (for this scenario) between the two approaches you’ve explained. Since the amount of time I have to work on it is limited (few hours per week), I needed something I could be very productive with and so far Rails, besides being very wrist-friendly, is the simple, productive solution I needed.

    It may seem subtle, but the time saved from not having to compile and set up build scripts solutions/projects/assembiles, etc. really adds up. Deployment is as simple as “cap deploy”.

    The only learning curve I’ve had to somewhat overcome is the interaction with Linux/Apache/Mongrel, etc.

    (I do have the added advantage that I plan on staying in the ministry work so I’ll be the one maintaining it as well.)

  • This conundrum is exactly why I am a fan of application frameworks. Good ones strike a balance between RAD and SOC etc. Lately, I’ve been checking out Dave Laribee’s XEVA framework.


  • You make very valid points that I think every developer faces. Usually my biggest decision maker is time. Although this not at AT ALL the way you want to proceed, but I have found that most clients are willing to risk short development at the risk of longer update time.

    On that note, there are certian measures you can take to protect yourself, which you mentioned. Even though you use the WYSIWYG tools, you can still do layering and such w/ little to time gain. This way, you can strip an entire layer if need be w/o upsetting your build too much.

  • @eric

    so from your point of view you have to manage expectations well so that your client understands the framework you chose. that makes perfect sense, but what happens when they need something outside of that? tell them “no” and just bite the bullet?


    i don’t always know who will maintain the app. probably me, but if i don’t know, should i opt for the easier solution?


    you’re talking about a framework that’s both simple and scalable. we’re in .NET, remember? :)


    if you find a good one, let me know. most app frameworks i’ve run into have a pretty high complexity bar to make it worthwhile.

  • > you’re talking about a framework that’s both simple and scalable. we’re in .NET, remember? :)

    Is there a reason you’re limiting yourself to .NET only? :D

  • Something that short term, I would likely use Rails despite my lack of experience with the platform. Something like that is likely to be more focused on the presentation (graphics) and layout and less focused on the back end. But there is plenty of back in Rails (membership list, maybe a calendar, who knows what else) and there are plenty of snap-ons that you easily integrate into the project.

    Plus it’s not too hard to find cheap rails hosting and deployment is a snap as well.

  • If they have a requirement for WYSIWYG then use those tools. If they’ve asked you to implement specific functionality without any real design restrictions, use whatever method you feel is best (possibly just for you) for the time constraints you have. YAGNI doesn’t really apply here because you’re using sound design. In the two-week period you might not need it; but the reason these design techniques were created is because software does evolve over time. It’s rare that software can be written in any time-frame that will be used verbatim for the rest of time.

    It’s not like you’d be using tools that no one uses if you choose the non-WYSIWYG route. The more you use NHibernate, likely the faster you will be at it; and at some point it will be faster than the other method…

  • Have you considered something like the Castle project ActiveRecord implementation? It’s built on top of NHibernate, IIRC.

  • Nick Gieschen

    For these smaller projects, I go with subsonic. It’s very easy to get up fast and has scaffolding support if you need to create an admin area. It creates domain objects for you, which means that the site can get quite complex before you run into problems. Moreover, the syntax is really easy, so some joe shmo who might need to maintain it, shouldn’t have any trouble. Of course, for a larger project I’ll go with NHibernate and an Evansesque approach.

  • @joey

    Sounds like we need a RoR install-fest in Austin.


    I keep hearing that. Sounds like I need to bite the bullet.


    I understand that familiar approaches are faster, and picking a good architecture helps you scale. I’m trying to figure out if there’s a threshold where less flexible technologies are appropriate. Not sure if there is one.

    @Gabe, @Nick

    When do you decide if a solution is complex? It seems that the supposedly short-term apps tend to hang around the longest.

  • The first question I’d ask myself in this situation is:

    How likely is it that I’m going to be introducing significant architectural changes? If I think it’s likely that the scope of a project is going to grow over time and I’m going to have to have a flexible design… invest the time to do it ‘right’.

    I think the real trick is being faced with new feature requests and knowing when it’s time to refactor things to a more flexible design (before it’s too late).

  • I’m curious: what sort of scenarios do you have in mind that are too complicated for LINQ?

    > When do you decide if a solution is complex? It seems
    > that the supposedly short-term apps tend to hang around
    > the longest.

    No idea :-)

    But I’m reading through _Design Patterns_ again, and the whole book in one sentence is “encapsulate the concept that varies”. I think the best you can do is choose a few of the axes along which you thing future variation is most likely, and make sure your architecture encapsulates those.

    About Rails, incidentally: I’m also building a web app for my church, and decided to use the experience to teach myself Rails. The actual development has been a joy, but I’ve spent almost as much time deploying it as I have developing it :-( . If you don’t have prior knowledge of linux/apache, it can be a pain.

  • @Jimmy,
    Hehe, well I can assure you’ll it’ll be a heck of a lot simpler than a VS InstallFest. ;)

    Indeed, I struggled with this myself, on purpose mostly by setting up my Ubuntu box at home. I like to “feel the pain” of something before looking to make it easier or have someone else do it for me. I ended up just getting a RailsPlayground account ($5/mo) and set up Capistrano accordingly. Now it’s drop dead simple “cap deploy” and it’s all good.

  • Why not Castle’s Active Record? Now you have the best of both worlds? Or SubSonic for that matter?

  • @Joe,
    Comparing Castle AR to the Rails stack is probably not the best comparison. AR is just a mere part of the productivity benefits you get with Rails, in my experience.

    However, if you must stay with .NET, I’d absolutely agree that a Castle MR/AR combo is a great way to get something up and running fast without sacrificing too much of the architecture.

  • I think the key question is the one Greg raised earlier, who will maintain it.

    If its likely to be you and you do see future complexity coming along then I’d go for a layered domain model based approach, but with something like a church website I might even be thinking active record (as Joe suggests). I say this because I’d imagine CRUD and a little bit of validation is as complex as it will ever get to be so active record might be a good choice.

  • Nick Gieschen

    Re: how do you know how complex it will get? It’s pretty much a feel thing. I mean, I can’t imagine a church site requiring you to do anything that would be a stretch for a subsonic project. Moreover, the fact that subsonic has good sproc support means it can’t do anything that any old traditional .NET site can’t do. (Of course, you don’t want to go down the sproc route, but if its a few one off reporting queries, it’s well worth the cost for the RADness you get.)

    In truth, for a church site, I’d tell the client to give me some $ to research and manage an offshore Joomla developer. With all the Joomla plugins it’s *really* easy and cheap to get something with a tons of generic functionality up.