Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,488

filter by tags archive

Applying YAGNI in Impleo

time to read 2 min | 384 words

The very first draft of Impleo (my CMS system), was based on sound design principles. It had good separation between the different parts (it actually had 4 or 5 projects). At some point I took a look at the code and couldn’t find it. There was a lot of infrastructure, but nothing that I could actually point to and say: “This is the application logic”.

I decided to take a different approach, created a new WebForms project, and started everything from scratch. I ported some of the code from the original solution, but mostly we just built new stuff. I stubbornly decided that I am going to apply YAGNI here, so I just scrapped everything that I usually do and started a typical web forms project, no IoC, no testing, nothing.

As expected, initially we had a really nice velocity, and if I had to hold my nose a bit during some parts, I was willing to go with that.

The next stage with Impleo, however, is to turn it from just a content management system into a website framework. The difference between the two are significant, while a CMS is just about content, a website framework allows you to add custom pages and application behavior. There is an added difficulty in that I want to use Impleo for multiple sites, doing different things.

That turn it from just a custom application to a platform, and the roles there are quite different. For that, just going with the approach that I used so far would have been disastrous. I tried, and spiked some things, but none of them made me  happy. I decided that I really need to stop, and since I have a working version, I can “refactor” it to a better shape. I put refactor in double quotes intentionally.

My method included creating a new MVC project, add some integration tests and then porting everything from the WebForms to the MVC project. Overall, it was a pretty simple, if tedious, process.

The most difficult thing along the way was that I was doing this while I was flying, and for some stupid reason, I could either charge the laptop battery or use the laptop, so I had to make frequent stops to recharge.


Ryan Riley

I suppose I'm still wondering, how did WebForms appear as a result of YAGNI? I realize that's the original ASP.NET platform, but MVC seems simpler to me, and even simpler would be starting with HTML, CSS, and JavaScript (or, heaven forbid, classic ASP) with some AJAX.


Any plans to open source it?



Because with WebForms you know you ain't gonna need it



Comment of the day ;)

Ryan Riley


I second Jonatan's comment!

John Farrell


MVC makes you care about a lot more things than webforms.

If out of the gates your just trying to render some database rows to a html page right clicking to add new page and then <% bee-stinging %> it out will be faster than setting up a controller, view, and routing.

Ryan Riley


So are you saying that creating a WCF service to expose data that could be picked up client-side by js (e.g. jQuery) is harder than WebForms? I suppose my problem is that I never liked the WebForms abstraction and find it completely mangles web development. Therefore, WebForms, to me, will always fail YAGNI because of its complicated abstractions and the need to turn off ViewState everywhere. I'd rather saddle up with classic ASP, PHP, or Ruby.

John Farrell


Your forgetting, as most people do, that you can have a classic asp/php experience with webforms all you want. You don't need controls, events, or viewstate to use webforms.

And of course a WCF is much harder to consume with jquery than spitting out the html I want with beestings and doing a get request the page I just made.

Ryan Riley


That's a fair point. I just don't see very many people heading that way when they speak about WebForms, so it doesn't cross my mind to allow for that possibility. Your point about jQuery is also valid, but that really depends on what you are trying to build. If you are building a client app and want to feed it data (i.e., not really just building web pages but a real app) the true nature of HTTP is served best by the web service + js approach. But that will lead us into a debate about whether or not REST is simple or complex, what does REST really mean, etc., and I find that I'm generally in the minority on those ideas. Perhaps it's best I just don't mention it. ;)



Setting up a WCF service is much more difficult than setting up a web form that talks to a DB, how anyone could see otherwise is beyond me.

I know we all hate Web Forms, yada yada yada, but if you need to just setup a few pages, it's dead easy and much faster than MVC, a WCF service or any other method to deliver content. Hence why it makes perfect sense in this "I'm using YAGNI to the letter of the law" experiment.

But the reality is, you rarely have a project where you can work in this pure YAGNI way, since there almost always is requirements such as make it testible, make it easy to maintain, make it SOE friendly, etc. so working in ASP.NET Webforms a poor choice for the job. But there does come a time where a project is "All we need is one page that shows data in a grid", it can be done in literally 10 minutes with a WebForm.

It's all about using the proper tool for the job.

Dmitriy Nagirnyak


Your own website framework?


What are the reason for starting it from scratch if there are some of them already available?

  • Exercise?

  • Lack of extensibility?

  • Wrong architecture?

  • "Just want my own" thing?

  • others?


Richard Dingwall

Article starts with YAGNI and ends up writing a whole new CMS from scratch! Ayende!!


no IoC, no testing, nothing

No, tell me it aint so Joe!

Dmitriy Nagirnyak

Actually this post reminds me about the "time of quality" and "I need this to work NOW" things. It seems that time definitely wins over quality here.


"I was doing this while I was flying"

Jet pack or glider? Its a wonder you could type and fly at the same time.

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Physically segregating collections - 26 minutes from now
  2. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - about one day from now
  3. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 4 days from now
  4. The design of RavenDB 4.0: Voron has a one track mind - 5 days from now
  5. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 6 days from now

And 12 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    03 May 2016 - Making Lucene reliable
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats