Costing a website or webapp: A guide for the non-developer

I won’t cover how estimates are produced, or how to conduct the actual project management – these are covered in loads of good books such as James Shore’s: “The Art of Agile Management“. What I want to cover here are initial techniques that you, the stakeholder, can do to help get the best estimated costs for your webapp or website.

The question “how much does it cost to build my website or webapp?” is like asking a builder “how much does it cost to build me a house?”. It totally depends of your requirements. As with all estimates, Requirements Are King.

“Requirements” are based on 2 fundamentals:

1. Your understanding of what you want
2. Your ability to communicate the requirements in a easy to understand way, and continue to communicate them as things change.

Even given detailed schematics, for custom, original projects that may change once building has started, the best any bricks and mortar builder can do is to provide a good initial estimate and then keep you updated as the project progresses. Web-app production is no different.

.NET MVC vs Ruby on Rails

Or rather, .NET MVC for Ruby on Rails developers.

Note: Some edits have been made in light of useful comments

It seems oddly regressive to be going from the polished world of Ruby and Rails to the rough hewn newborn lump of .NET MVC, but well, needs must. I’ve just finished a project in .NET MVC (RC1) and have the following thoughts that may come in handy if you are thinking of using .NET MVC instead of Rails, or are a Rails dev being forced to use .NET MVC:

1. Learn C#. The most straightforward book I found was the Apress C# book Pro C# 2008 and the .NET 3.5 Platform. You’ll only need the first half of the book.
2. .NET MVC is easy to grasp if you have any prior MVC web framework experience such as Rails. Do a couple of video’s of the .NET website.
3. .NET MVC is actually .NET VC. It is an attempt to replicate the Actionpack components of Rails. There is nothing included aside from a folder labeled “Models” to help you with your persistence later and domain modeling. As others have mentioned, there are other ORM tools out there, but bear in mind these are not integrated into the framework as with Rails. There are good and bad points to this, but it does mean you’ll be writing more boilerplate code and setup for your model layer than you are used to with any of the Ruby ORMs.
4. The community is comparatively extremely anemic, both in terms of plugins/modules and blog posts/tutorials. After the well developed ecosystem of Rails (500+ people in IRC, loads of blogs/tutorials/newsgroups, rubygems, github etc), don’t expect to be able to rely on much else other than the .NET libraries, core MVC and Contrib packages and a handful of blogs. It is still early days for the framework, but the lack of community resources will come as a culture shock.  That said, a good resource for tips is stackoverflow.com, developed using MVC .NET. From a code point of view, you will often find yourself writing model wrappers around normal .NET components, such as the Membership API, in addition to doing more setup XML pushups than you are used to.
5. The official documentation is rudimentary. Even within the framework code, comments for methods are often non-existent. The DocRails and Rails Guides projects are good examples of how to get the community documenting the codebase and building a range of real world explanations. Unfortuanatly there is nothing like this for .NET MVC as yet, the framework is also not documented on MSDN at this stage.
6. The API feels un-unified with different argument requirements for very similar methods. Programming to an API which is undocumented and un-unified can be quite vexing even with intellisense code completion doing the hand holding.
7. .NET MVC is now NOT open source. Next step in joining the OSS community is accepting contributions.
8. The routing will appear very verbose in comparison to the simple rails routing structure. That said, it does work and is round trip.
9. C# is too verbose for most web work. This point really should not be underestimated. Edit: not really a fair point in this discussion
10. All Ajax is done by hand (not such a problem, as it includes the jQuery library).
11. Passing variables to the view can be extremely laborious. There is the ability to automatically pass objects of 1 type to the view using strongly typed views. Outside of that, you have to package/box up your variables into an array which gets sent to the view. In the view, you have to unpack/unbox the variables from the array and cast them to their original type before use. As you can imagine, this gets old, fast. This also leads to old .NET hands just coding everything in the view in a codebehind to “get the job done”. Edit: Another way round this from the comments is to make a custom composite object and pass this through to a strongly typed view. I’m not entirely sure how this reduces the effort required, but it is certainly true that the methodology advised in most of the Docs is to use the ViewData collection to pass variables to the view using a “package and pass” approach.
12. It’s hard to convert ASP.NET developers to use .NET MVC as it is basically less immediately productive, and can feel like a step-backwards in their approach to webdev.
13. As the MVC project is very much a reactionary response to staunch the outflow of devs to other MVC frameworks, there is a worry that MS will drop the project if forced to make a cost cutting decision (see licensing comment 6). They are certainly not going to drop normal ASP.NET. If MVC .NET is properly open sourced, this is less of an issue.
    

The list really does go on, but I guess this will do as a brain dump on my main impressions so far. After this brief first pass, I would say the features of .NET MVC 1.0 are similar to rails in the 0.7 days (’04/’05) without the ORM.