Some languages are made for large teams, and some are made for the individual. It's not just the language, but the supporting framework and tools that are associated with the language.
For example, C# (with the the .NET framework) is a language designed for large teams. The framework is large, much larger than the previous generations of MFC and ATL. The .NET framework has hundreds of namespaces, thousands of classes and tens of thousands of methods. It is much larger than any one person can consume. When building a non-trival application in C# and .NET, the natural response is to divide the work among several people. Not just hire multiple people to work on the project, but to specify different areas for different individuals. The traditional big areas are database design, user interface, and business logic.
The C# language supports this division of labor. So does the .NET framework and the tools offered by Microsoft (Visual Studio and Team Foundation Server). Microsoft recently added the "partial class" feature to C#, allowing multiple individuals to work on separate parts of the same class.
A language designed for a large team leads to large teams. And once you have large teams, you need managers.
On the other end of the scale, languages for individuals work well for a single person but poorly for a team. I think of the languages Forth, Perl, and Ruby as languages for individuals. The languages (and their supporting libraries) are small enough for a single person to understand. Individuals can create and maintain capable applications without the division of labor among multiple workers, and without the oversight of managers.
It seems that languages (with their libraries and frameworks) cannot be both large and small. They must be one or the other. A language -- for example C -- may start small and grow complex -- into something like Visual C++ with MFC -- over time. But those are two different implementations.
Managers have an interest in the selection of language. Languages that lead to large teams are better for managers -- at least better when the manager has an incentive to build an empire. Languages that encourage large teams let managers build those empires. They also let managers partition the work among their staff, and support the manager in that partitioning. Languages for individuals do not encourage large teams, nor do they support the manager in partitioning the work. With languages for individuals, the work of partitioning work among multiple people is harder -- the manager must do it himself, and there is no guarantee that one person will remain within his (arbitrary) limits.
So we have the effect of language design on team organization. Languages for large teams will be used by large teams, but will also grow small teams into large teams. Languages for individuals will be used by individuals, and discarded by large (or even medium-sized) teams.
What does this mean for the future? Will we see a bifurcation of the development world? Will we see one "world" of development for corporations with large development efforts and a second "world" of individual developers? If individuals are not working on corporate projects, what will they work on? (iPhone apps, perhaps?)
No comments:
Post a Comment