+972 52-548-6969
Applying YAGNI in Impleo
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.
Comments
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?
@Ryan
Because with WebForms you know you ain't gonna need it
@Rafal
Comment of the day ;)
@Rafal
I second Jonatan's comment!
@Ryan
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.
@John
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.
@Ryan
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.
@John
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. ;)
@Ryan,
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.
Ayende,
Your own website framework?
Hmm.
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?
Cheers.
Article starts with YAGNI and ends up writing a whole new CMS from scratch! Ayende!!
No, tell me it aint so Joe!
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.
Sorry, should be "time OR quality".
"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