Jason M. Hanley :: Custom Software Developer

The other day, I was wondering to myself, “What are the most popular web frameworks right now?” Finding accurate numbers is actually pretty hard, so I decided to go to the expert: Google.

Sometimes you can (very unscientifically) determine something’s popularity by simply noting how many references Google has to a particular keyword or phrase, so here are the current results:

Web programming languages:

• ASP.NET: 86 million
• Ruby: 101 million
• PHP: 2.95 billion

Specific web frameworks:

• Symfony: 4.6 million
• CakePHP: 4.8 million
• Ruby on Rails: 5.4 million

I was really surprised that PHP beat ASP.NET by such a wide margin. I was also happy to see that Symfony (my framework of choice) was holding its own against CakePHP and RoR.

It was really surprising to see that Ruby had more references than ASP.NET. Perhaps I’m not searching for the right string. I’d be interested to hear others’ results.

People always try to tell me that IIS / ASP / ASP.NET is just as stable as Apache / PHP.

The Canada Post website has been down for hours, simply displaying:

A ScriptEngine threw expection ‘C0000005′ in ‘IActiveScriptParse::ParseScriptText()’ from ‘CActiveScriptEngine::AddScriptlet()’.

I know C0000005 errors well from my Win32 C++ programming. It’s a generic “access violation” or crash error. It means something is seriously wrong.

Now, you can tell me, “They haven’t applied patch X”, or, “They haven’t configured Y properly”, but I see this sort of thing all over the net. Even Microsoft’s own pages have these errors from time to time.

On the other hand, I rarely see PHP error messages. Even when I do, they’re typically “can’t connect to database” timeouts on an overloaded server, as opposed to major system crashes like the message above.

I continue to assert that Apache/PHP is generally more stable than IIS/ASP.

A common problem with software development project management is that most people don’t really understand how it works. Programmers are often likened to construction workers. Managers view them as skilled labour, like a carpenter or brick-layer. If you want something built faster, you hire more people, and things go quicker.

Software engineering is a different beast, though. Fred Brooks wrote The Mythical Man Month in 1974, and it is often considered the “bible” of software engineering. In the book, he explains how creating software is different.

Brook’s Law states that “Adding manpower to a late software project makes it later.” It’s important to keep teams small and agile, especially in the early stages when the architecture is in flux.

Creating usable, high-quality software takes a lot of time, skill and experience. Trying to cut a deadline by adding more people will almost guarantee the opposite effect.

I’ve created a web development summary chart comparing the major web application development platforms out there today. I’ve tried to make the comparison as unbiased as possible, and stick to mostly to business and technical reasons for choosing each one.

As you can see, there is no one perfect platform. They are all very capable, and which one you go with depends a lot on your business priorities.

Estimating software development time is hard. There are so many variables, unknowns, “unknown unknowns”, and the specification always changes. Besides that, developers tend to be optimistic by nature.

Here’s a handy little way to come up with a quick, yet accurate estimate:

1. Come up with your best, overall estimate that you feel is realistic using your favorite technique, or pure “gut feeling” if you are a very experienced developer and you know the problem domain well.
2. Ok, you have your absolutely realistic number now, right?
3. It’s not realistic. I guarantee you there are aspects you haven’t thought of. Double the number. This is your best case scenario estimate. This is how long it will take assuming everything goes well and there are no snags or major changes along the way.
4. Now double it again. This is your most likely estimate. This is how long the project will probably take, when all is said and done.
5. Now double it a final time. This is your worst case scenario. If things go really badly, or you run into several major issues, it could take as long as this.

So to sum up:

• E = Your best original time estimate
• 2(E) = Best case scenario time in reality
• 4(E) = Most likely time in reality
• 8(E) = Worst case scenario time in reality