Also add:

- iPhone vs BlackBerry: BlackBerry has a server to manage 1000s of phones, update, delete, reassign, track. So you need “Management tool scalability”.

- Updates, branches, versions, special editions: with a lot of customers some can’t update to your latest version, integrations are broken and so on. “Parallel code branch” is a bad word, but you will have it.

- Process: any larger (>100 people) company will need it. If it’s too light it’s useless, if it’s too heavy the shortcuts will kill it.

- Complexity: there will be no single “go to person” with all your issues. This will lead to silos (can be mitigated somewhat with a good process).

- Regulatory: FDA, FCC & co means “Change management”, from requirements to compliance, complaints and resolution.

- Spotlight: anything you do somebody will hate it and will blog/tweet about. So you will have to have answer for any action or inaction.

Basically expect to have issues you never thought about.

Can your tool handle 15,000 users with administrative rights? Do you track (audit and log) every action? Do you know every single point of failure you have and do you have a solution for that?

A very true point.

Excellent people make excellent teams, and a living application is only as good as the team that supports it. Hire excellent people and many of the goals identified above will follow. The problem is, it is very difficult to locate and hire excellent software engineers. You need a strong process and the discipline to not hire out of desperation.

I agree with Scott McPhee’s comment when he says that #5 above helps to define an “enterprise” application, and is not necessarily a problem to be solved. Large problems often require solutions with many internally complex parts that work together. One of the challenges is to put them together in simple, elegant ways that do not limit your application’s potential.

Finally, I’d say that you shouldn’t “fight” to keep your greenfield green; rather you should tend it like a garden. Good gardeners make a good garden. Good soldiers make a good battlefield.

The idea is not without it’s faults. If the conductor is too aggressive, of course, they can drive off talent. And, this better be put in the hands of someone who can and wants to get it all done. But there’s nothing to say the conductor hat can’t move around after a while.

Too many cooks spoil the soup. And once the number of people grows past, say 1, I find that someone starts to take up a dominating position anyway. Might as well try to make it official and respected, rather than just tell people to “you know, here are some specs and goals, go figure it out”.

And it’s a lot easier for 1 person to say no.

In my experience, developers might think all the other points are the hallmarks of an “enterprise” app but I’ve seen all those features in a hokey little website-to-database applications built and maintained by three people, and none or few of them inside large companies with an entire coterie of teams working on a variety of systems.

What is termed here as an “enterprise” system is just poor professional practice. If you strive to craftsmanship then good systems are possible to build in any environment. What the post commends as “fight it every step” I would say, be disciplined enough to show it at every step.

All apps suffer from code rot and technical debt – learning to keep those things in check is important as you imply here. (see Jeff Atwood’s post at: http://www.codinghorror.com/blog/archives/001230.html – it’s awesome)

Scaling applications up is not a bad thing though – and as long as you follow the guidelines you listed and continue to use your brain – you can avoid being overwhelmed by technical debt – even for a large Enterprise Application.

I can understand though, why the dynamic language community would be a little perturbed by large scale applications – dynamic languages are not the right tool by themselves to compose a large system – though they are perfectly suitable to be a part of the solution. Scaling up means adding complexity (in my view complexity is a function, probably an exponential function of number of features). Current dynamic languages do not provide the structure by themselves to deal with complexity after a certain point. So if a dev thinks just knowing Ruby and Python is going to allow him/her to work on highly sophisticated apps – he/she is going to be extremely disappointed when they try it.

The most important thing you can do

is

Learn To Say No.

http://www.joelonsoftware.com/items/2006/11/21.html