Interesting article. I think using viscosity to compare languages or frameworks is counterproductive, but the general idea is useful when talking about software architecture and development.
For instance, I used to manage some poorly architected Java apps where even trivial changes incurred painful re-architecting because the app was poorly written. And I've managed PHP apps that are extremely well-organized and are very simple to add functionality to.
The other thing I'd mention is I like your idea about hitting the wall where improvement freezes b/c the implementation time is so great. I think it's a good fit for the technical drag model -- that is the point of terminal velocity!
It's another good-fit for the metaphor; eventually you can only drive forward a product by making the team bigger because your project hits its terminal velocity (or top speed) for the given "engine" size (the team).
One problem with that concept of adding developers as increasing the size of the engine - I don't think it works like that. When development freezes, good developers end up losing interest eventually, so in reality what probably happens is that your productivity decreases - so in fact you probably start regressing, if you let yourself hit that point.
For instance, I used to manage some poorly architected Java apps where even trivial changes incurred painful re-architecting because the app was poorly written. And I've managed PHP apps that are extremely well-organized and are very simple to add functionality to.
The other thing I'd mention is I like your idea about hitting the wall where improvement freezes b/c the implementation time is so great. I think it's a good fit for the technical drag model -- that is the point of terminal velocity!
It's another good-fit for the metaphor; eventually you can only drive forward a product by making the team bigger because your project hits its terminal velocity (or top speed) for the given "engine" size (the team).