How Do We Measure Maturity In Software?

How Do We Measure Maturity In Software?

When I saw a post by Jeffery Palermo entitled “Is Classic WebForms More Mature Than ASP.NET MVC?” I immediately thought “Aha! I know exactly what he means!” And then I read his article and realized that while the post was good, it wasn’t at all about what I thought it was going to be.

In his article Jeffery talks about the platform and the tools which are still in place from “classic” asp.net as a means of showing that all we are doing is really just switching out the top layer software abstraction. We still have this proven, reliable, robust base that is underneath running the whole thing. And trust me, I completely agree with this sentiment. What I thought he was going to point out though is a slightly different scenario, and it requires us to narrow down a bit our definition of what exactly “mature” software is.

So, what is mature software?

Is mature software defined by the amount of time that the software has been on the market? Many times we will call a person mature because they have been around for a long time, but I highly doubt that we should be measuring software maturity based on whether or not it would get a discount at the Shoneys buffet. Sure, you could argue that software which has been around longer has had more time to shake the bugs loose, but unless someone is fixing those bugs, I wouldn’t say that software ages like a fine wine or anything.

If software’s maturity cannot simply be measured by how long it has been on the market, yet time in the market is clearly an indicator of how mature a piece of software is, then what is the factor that we are measuring here? I would say that we are measuring the software’s evolution in two distinct ways.

First we are measuring how “solid” the software is. This can be broken down into several different qualities as well, but I will just stick with a measure of defects. Over time the number of defects will hopefully be on the decline as a piece of software matures.

Second we are measuring how well the software has evolved to fill its role. Over time we assume that a piece of software is going to change with market pressures to become something that fills its role better than when it was originally released. This is a relative measurement, but given a particular piece of software you could probably find some ways to measure it. I think that this measurement also includes how well a piece of software has adapted to keep up with its market, as its market is changing.

Overall I think that this points to the fact that what we are really measuring is the delta of a tool’s effectiveness. Over time tools tend to become more and more effective. Whether it is because a new feature is added or because bugs have been found  and removed, software usually becomes more “mature” over time because we have had a chance to make it better.

So if we measure ASP.NET WebForms and ASP.NET MVC against these measurements, then where does each fall?

ASP.NET WebForms clearly has an advantage when it comes to time on market, but how does it stack up when we start looking at defect numbers? Well, the release early and often approach that the ASP.NET MVC team has taken will almost certainly result in fewer bugs in the initial release of ASP.NET MVC versus ASP.NET WebForms. ASP.NET MVC has had 6 preview releases, a beta, a release candidate, and a release candidate refresh, all the while the source code was completely available to the public. People have been running production sites on this code for almost a year now. Let’s just suffice to say that the quality is going to be high, and will likely be higher than the code coming out of ASP.NET WebForms.

Now, when it comes to measuring how well a piece of software has evolved to fill its role… well… I’d actually say that ASP.NET MVC has a huge advantage in this space. ASP.NET has really only had two major releases with some service packs in between. As I said earlier ASP.NET MVC has already had 9 public releases with significant changes during each release that were in direct response to customer feedback! I would say that ASP.NET MVC has evolved more to what the market has demanded in its short life than ASP.NET WebForms has in its entire life. Now this is due to the fact that Microsoft has to keep ASP.NET WebForms stable and can only really add features onto the periphery,  but I don’t think this fact negates the speed at which ASP.NET MVC has been changing.

I just don’t think the concern about ASP.NET MVC not being mature is a valid concern, and sounds more to me like people that just don’t want to invest into moving to another platform. ASP.NET MVC is solid, evolving, and will also have a ton of community support through projects like MvcContrib. ASP.NET MVC will also be an out of band product which will allow it to evolve faster, and keep up with customer demand. Whether this will affect its long term stability will remain to be seen.

The question that I hear over and over again is will ASP.NET MVC end up eclipsing WebForms? I think the jury is still out big-time on that one. It is all going to come down to how well Microsoft pushes and endorses the platform, but so far it is looking pretty good. I just hope that people don’t use the excuse that ASP.NET MVC is immature as a reason to not even give it a second look.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (4)

  1. @Jeffrey True, but by the time that WebForms hits a beta, they have already finished design. As you know, they go far out of their way to avoid making any changes past that point. Now I know that this is because they have to integrate with the rest of the product line in order to ship, but the amount of public use and then changes based on that just doesn’t happen in the in-band products.

  2. Although I agree that MVC is moving fast forward with its rapid deployment cycle, IMHO maturity has to do more with number and volume of applications utilizing particular technology than number of releases it went through. In this respect, MVC is relatively immature (untested). Still, can’t wait to use it 🙂

  3. @rtur I’m not sure that the number of applications using a particular technology really has any bearing on its maturity. For example, I would be willing to be that Java has way more applications in existence than Python, but I certainly wouldn’t say that Java is a more mature technology than Python. I’m not entirely sure that I follow your logic.

Leave a comment

Leave a Reply

Your email address will not be published.

More Insights

View All