Posted about 5 years ago on May 31, 2009
Since the release of ASP.Net MVC, one of the major talking points has been: When should I use MVC and/or webforms, and will it save or cost me time. These are my thoughts.
Consider the following:
Velocity is the number of feature hours (or feature points) completed in a given iteration (or time period – given that the time period is constant).
Why does it take longer to gain velocity with MVC?
As ASP.Net web developers we’ve been developing with a mammoth abstraction that’s made a ton of our design decisions for us. To achieve velocity with webforms, you really needed only a cursory understanding of how the web works. Contrast that with ASP.Net MVC, which puts developers closer to “the metal” and forces us to make intentional decisions about the design of our apps. Because of this freedom (and power) we’re also responsible for making sure we don’t make the wrong decisions, so it takes a great deal of critical thought and planning to make it what you want it to be.
Once your design and opinions have been established, velocity is likely to increase and then stabilize. Why? Because if you’re doing it right, then you’re designing with SOLID* principles in mind (something that’s extremely hard to do with webforms). Complexity is minimized and entropy is mitigated.
What’s with the sharp decrease in velocity with webforms?
Because it’s so hard to create SOLID* apps with webforms, complexity grows and grows until it’s out of hand. Release cycles go from weeks to months to quarters, and then the app that the company invested millions of dollars in needs to be rewritten because the cost to maintain and/or extend outweighs the cost to start over.
What do you think?
*SOLID principles are not new and whizbangy. They’re a different name and face on what’s been known about OO since the first OO languages, and what every CS college student should have learned in OO design 101.