Project Risk
http://www.whysmalltalk.com/articles/robertson/analysts.htm
Gartner’s numbers are from 2002, but they pretty much apply TODAY as well. Java, Visual Basic, and C++ are still the most prominent of the mainstream programming languages. And the stats on failed software projects couldn’t have changed much in the last 5 years...
Depending on your definition of “failure,” anywhere from 40-70% of all software projects fail to satisfy their key requirements—either they come in very late, or very over-budget, or they just don’t meet end user expectations. “An inordinately large number of large-scale Java projects have been failures.”
Now, far be it from me to blame the failures on the language tools. There are many reasons why projects fail, and very often the finger points to bad management or bad communication or bad analysis. The choice of language tools rarely contributes to failure (though it may cause teething problems and the like). It stands to reason, then, that choosing a non-mainstream language should not significantly increase project risk (unless you choose something really far out on the fringe, like OCaml, Erlang, Haskell, or Lua).
[As an aside, I suggest that Smalltalk is a better choice than Lisp because, while Lisp is not a fringe language, it is quite alien-looking compared to most other languages. At least Smalltalk resembles English in its syntax and is thus extremely readable.]
But why choose an alternative to a mainstream language? Java, Visual Basic, and C++ have been amply proven in the field, and there are huge ecosystems surrounding these languages. Skilled people in these areas are easy to find.
The answer is high productivity, quick and easy prototyping, lower programmer stress, and lower defect rates in the software, to name a few advantages. Some of these help to shorten a product’s time to market. Others improve the chances of meeting end user expectations. But in particular I want to touch on lower programmer stress...
Using a language tool that is simple and easy to master helps to avoid the cognitive effort in managing the complex of language features found in today’s mainstream languages. There is no question that this cognitive effort—subtly, cumulatively, and over time—contributes to programmer stress. People in the software engineering field know exactly what I’m talking about (or perhaps not—it may be too subtle for them to notice). But even if they don’t notice, the stress is still there, and the long-term consequences may include burn-out or job-hopping.
Choosing a language tool that addresses a programmer’s cognitive nature would preserve the efficiency (and sanity) of your programming staff. It may help to reduce turnover and perhaps even improve morale. How can this not be good for your software project?!
With all due respect to Joel Spolsky, he’s dead wrong. Choosing a mainstream language does not significantly improve a project’s likelihood of success, and as Gartner’s data show, it may actually worsen the chances! Choosing something like Smalltalk does not entail greater project risk, and it promises benefits that absolutely cannot be found in today’s mainstream languages.
Gartner’s numbers are from 2002, but they pretty much apply TODAY as well. Java, Visual Basic, and C++ are still the most prominent of the mainstream programming languages. And the stats on failed software projects couldn’t have changed much in the last 5 years...
Depending on your definition of “failure,” anywhere from 40-70% of all software projects fail to satisfy their key requirements—either they come in very late, or very over-budget, or they just don’t meet end user expectations. “An inordinately large number of large-scale Java projects have been failures.”
Now, far be it from me to blame the failures on the language tools. There are many reasons why projects fail, and very often the finger points to bad management or bad communication or bad analysis. The choice of language tools rarely contributes to failure (though it may cause teething problems and the like). It stands to reason, then, that choosing a non-mainstream language should not significantly increase project risk (unless you choose something really far out on the fringe, like OCaml, Erlang, Haskell, or Lua).
[As an aside, I suggest that Smalltalk is a better choice than Lisp because, while Lisp is not a fringe language, it is quite alien-looking compared to most other languages. At least Smalltalk resembles English in its syntax and is thus extremely readable.]
But why choose an alternative to a mainstream language? Java, Visual Basic, and C++ have been amply proven in the field, and there are huge ecosystems surrounding these languages. Skilled people in these areas are easy to find.
The answer is high productivity, quick and easy prototyping, lower programmer stress, and lower defect rates in the software, to name a few advantages. Some of these help to shorten a product’s time to market. Others improve the chances of meeting end user expectations. But in particular I want to touch on lower programmer stress...
Using a language tool that is simple and easy to master helps to avoid the cognitive effort in managing the complex of language features found in today’s mainstream languages. There is no question that this cognitive effort—subtly, cumulatively, and over time—contributes to programmer stress. People in the software engineering field know exactly what I’m talking about (or perhaps not—it may be too subtle for them to notice). But even if they don’t notice, the stress is still there, and the long-term consequences may include burn-out or job-hopping.
Choosing a language tool that addresses a programmer’s cognitive nature would preserve the efficiency (and sanity) of your programming staff. It may help to reduce turnover and perhaps even improve morale. How can this not be good for your software project?!
With all due respect to Joel Spolsky, he’s dead wrong. Choosing a mainstream language does not significantly improve a project’s likelihood of success, and as Gartner’s data show, it may actually worsen the chances! Choosing something like Smalltalk does not entail greater project risk, and it promises benefits that absolutely cannot be found in today’s mainstream languages.
posted by Darkest Knight | 7:01 PM
1 Comments:
Truly large and complex software projects are extremely difficult to manage properly and thus are prone to failure. The problems inherent in large, complex projects outweigh any benefits from the choice of forward-thinking language tools. So it doesn’t really matter what tools you adopt for these kinds of projects...they’re probably doomed to failure anyway (Gartner says 70% failure rate for Java/C++ projects).
But **if** the project is well-managed, then you can start to look at how to improve the technical aspects of software development—coding, debugging, testing. This is where your choice of language tool will have its greatest impact, keeping in mind that more than half of the software lifecycle (including maintenance) is spent in the coding trenches...
For projects that are not so big and complex, I strongly recommend you look at Smalltalk.
Post a Comment
<< Home