By the way, my experience as a software engineer, and senior lead engineer at that, is there are normally 8 people involved in a single product from creation to launch and through marketing on the average. You take $100k divided by 8 people and you have a cost of $12,500 per person per product. Compare that to the $3m figure and and assume the same 8 people more (even though it was closer to 20-30: engineering was horribly bloated back then) and you have a cost of $375,000 per person per product. So you have a drop in costs of 30 times cheaper per person per product.

Now, since salaries are fairly flat over the time period, we can assume that it takes less time for each product to be made. Given that, we can assume the engineers are more productive. When you can fit 30 projects in the same time frame of 1 project before, you can claim that engineers are indeed far more productive than before.

The means of this productivity is also the engineers own doing. Open Source software is created by these same engineers to save time in future projects. So having engineers ensures you of more productivity gains through the nature of the engineers themselves. Go figure.

Open Source engineers do this often. Corporate engineers – not so much.

The part you are right at is the 5 versus 50 engineering part. If you are expecting all 50 to be working on the same project. Quite simply, one project rarely ever has enough work to keep more than 6-8 engineers busy at the same time: I’m including UI and backend in here – toss in qa or uat and you can get another 3-4 people on. You simply have too many bottle necks in the standard application to keep them all busy without someone going off on some tangent elsewhere. But if you took that 50 and made 6-8 projects or products with them .. Gold mine.

And that was the point of the article. Stock up on engineers and crank out a ton of product from the overflow. The more productive they become, the more products you can create at one time. It’s a no brainer that if you can get more products out the door than your competitor, you will gain top of the mind awareness faster, more people will look to you for new products, and you win the game.

But what is missing most of the time is the “glue” to adapt to the customer needs:

- Professional services engineers
- Documentation
- Engineers meeting customers to gather needs
- Internal and customer training
- Etc …

It’s one thing to have a theoretically great software, it’s another to have happy customers able to build on top of your software …

Languages such as Python and Ruby are built with programmer productivity in mind and they come with extensive libraries. I still remember the days when I used to bang my head against the wall trying to program in Win32 and MFC. Java swing and Qt provided some respite, but they had their own drawbacks. These days, the .Net stack, MS Visual studio and MS Expression make cooking up ultra-cool distributed apps with kickass GUIs a *breeze*.

The corollary is that now is the best time to be in software development. The individual developer’s productivity is so high that we can conceivably create valuable IP on our own, stuff that would have taken an entire development team just years ago.

Consistent with Hoffman’s observations, what took a test team of 35 people to do 10 years ago, only took 12-16 people 5 years ago, and takes 5-7 people now. The net result is that quality assurance in software-based systems is becoming less people intensive.

What is amazing, or counter intuitive, is that this declining trend is occurring in the presence of larger and more complex software systems. Systems are getting bigger (measures by lines of code) and more complex (by any measure, most notably interconnects) and tend to be more prone to errors (e.g., missing features, usability, improper coding, etc.). As such, more testing is often needed to ensure the systems operates according to specification.But it isn’t. Why?

What is implied in the research is that while complexity is going up, the capability of testing is driving down the need for people faster. This is something we have seen in other areas where software-based automation is used as well (consistency). In the end, it all makes sense.

it’s not impossible to code a basic webform, however you may very well fail even with rockstar coders if user experience blows / user adoption sucks, and your acquisition is poor.

The truth is that very few management types are willing to deal with a crew of hyper-creative type engineers. It’s too much risk. Managers get fired for taking risks.
It’s much safer for a manager to hire off-shore drudges at low cost, complain that their work is sub-standard, hand it over to some average local programmers for repair, and come out looking like a hero for ’saving’ the project.