Spence Green

A colleague wrote the following note to me today:

I am trying to fathom what you have against an additional library into the architecture. The AJAX framework provided by MS$ is an additional library we have to use, there are Oracle libraries we have to use…what is the roadblock you have with an IronRuby, IronPython, or Lua library? Limiting the number of libraries, selective in the process is essential, but if to restrictive, can ignore industry standard flexibility in our system.

My reply follows:

I’m not limiting the inclusion of other libraries. I prefer to think about the problem first, then select the best method of expression. Language is simply that: a method of expression. It is almost always better to program in the language–namely, through the use of native syntax–than to program through it. The latter mode is a common mistake: have you ever seen someone write Java as if it were C?

An ad hoc approach is the alternative. In this case, we choose technologies first and solve problems later. This technique is used often in OSS. Here you must recall the essential difference between commercial software development and experimentation. Read this post.

We don’t exercise all of those steps here because we don’t do proper software development. The lesson, however, is this: the decisions that you make as a coder have lifecycle costs associated with them. Think about it: you include library X. We have to learn that technology. I&T has to test it. CM has to integrate it into the nightly builds. Maintenance has to update it, changing custom code as necessary. A whole succession of maintenance programmers for the next 5-10 years must follow this process.

You must also consider the risk of the technology disappearing during the software’s lifecycle. This is always a risk in software, but it can be approached intelligently. Microsoft has made a significant capital investment in .NET, and they have included AJAX in .NET 3.5. Moreover, other companies have staked their viability on .NET (incidentally, this is the anti-trust argument against Windows in the enterprise space: companies cannot afford to move away from it). Can you say the same for other technologies? Perl was the “next” silver bullet in 1995, but we are still waiting on Perl 6. In the meantime, it has been superseded by faster bullets: Python, Ruby, and Scheme.

I recommend that you read the book Beyond Software Architecture by Hohmann. Technology decisions cannot be made in isolation because they impact the business. The converse is also true. We must always be thinking not only in terms of “wow, this is cool”, but also in light of the question: “Does this make good, long-term business sense?”

I’m not trying to limit your creative freedom. I am trying to show you that we must make considered decisions at this point in the “cone of uncertainty.”