Reacties op: Is it possible for a small company to switch their development language? http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/ designing a new generation of software Wed, 09 Jun 2010 14:14:14 +0000 hourly 1 http://wordpress.org/?v=abc Door: Jon Harrop http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/comment-page-1/#comment-271 Jon Harrop Wed, 26 Sep 2007 04:38:19 +0000 http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/#comment-271 Our company made such a change about 3-4 years ago when we ditched C++ and moved onto functional languages. We initially just wanted to learn OCaml, having heard rave reviews from many different people. Our first project in OCaml was a simple rewrite of our main product (visualization software). After only 4 months we were not only proficient in the new language but had also done so much development that the rewrite was as functional as the original code base, four times shorter, five times faster and vastly easier to develop! So we made the decision to ditch the C++ code base (and object-oriented programming in general) and develop only the OCaml. Following the growth of OCaml and the recent introduction of F#, we are much more successful as a business now than we ever were then. Granted that luck played a big part (we were not expecting OCaml to take off as it did) but the ability to monopolize a smaller market rather than compete in a larger one turned out to be very lucrative for us. Indeed, I'm not sure we would have survived had we stuck with the old technology.   Our company made such a change about 3-4 years ago when we ditched C++ and moved onto functional languages.
We initially just wanted to learn OCaml, having heard rave reviews from many different people. Our first project in OCaml was a simple rewrite of our main product (visualization software). After only 4 months we were not only proficient in the new language but had also done so much development that the rewrite was as functional as the original code base, four times shorter, five times faster and vastly easier to develop!
So we made the decision to ditch the C++ code base (and object-oriented programming in general) and develop only the OCaml. Following the growth of OCaml and the recent introduction of F#, we are much more successful as a business now than we ever were then. Granted that luck played a big part (we were not expecting OCaml to take off as it did) but the ability to monopolize a smaller market rather than compete in a larger one turned out to be very lucrative for us. Indeed, I’m not sure we would have survived had we stuck with the old technology.
 

]]> Door: Dantelope http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/comment-page-1/#comment-270 Dantelope Wed, 26 Sep 2007 01:14:05 +0000 http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/#comment-270 If the primary reason for a rewrite is to use a "better" language or framework, then you have failed before you've even started.Companies do not fund such undertakings because they are in the business of making money, not provide an education for their developers in new languages.I find it humorous that people want to rewrite applications that are only a few years old.  I worked for an insurance company in 2002 that was using COBOL code with an initial release date of -- brace yourself -- 1965.  They are just now getting around to rewriting portions of it that no longer make sense, but I'll tell you this as a businessman...Do a mental calculation of the real return on a rewrite.  Did you get the benefit out of the last release?  When will a rewrite pay the company back -- and make sure to include the risk factor for project failure since a huge percentage of IT projects can be deemed failures (either not finished, didn't meet requirements, went well over budget and time, or were outright rejected by actual users).Wanting to do a rewrite in a different language with a different framework is the sign of a good developer/architect.  Knowing when that makes sense is the sign of a good principal developer/architect.My $0.02.  May be worth less in your neck of the woods.Dante  If the primary reason for a rewrite is to use a "better" language or framework, then you have failed before you’ve even started.Companies do not fund such undertakings because they are in the business of making money, not provide an education for their developers in new languages.I find it humorous that people want to rewrite applications that are only a few years old.  I worked for an insurance company in 2002 that was using COBOL code with an initial release date of — brace yourself — 1965.  They are just now getting around to rewriting portions of it that no longer make sense, but I’ll tell you this as a businessman…Do a mental calculation of the real return on a rewrite.  Did you get the benefit out of the last release?  When will a rewrite pay the company back — and make sure to include the risk factor for project failure since a huge percentage of IT projects can be deemed failures (either not finished, didn’t meet requirements, went well over budget and time, or were outright rejected by actual users).Wanting to do a rewrite in a different language with a different framework is the sign of a good developer/architect.  Knowing when that makes sense is the sign of a good principal developer/architect.My $0.02.  May be worth less in your neck of the woods.Dante 

]]> Door: Andrew McVeigh http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/comment-page-1/#comment-268 Andrew McVeigh Tue, 25 Sep 2007 22:04:52 +0000 http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/#comment-268 yes, rewriting is a huge risk.  the problems of the "big rewrite" are also related to the dangers of Second System Syndrome (Brooks) where the 2nd system is designed to solve all the problems of the 1st, but ends up becoming overengineered and never delivered.(however, sometimes (rarely), a rewrite makes sense.  i've seen it work to perfection in a tiny number of cases, but i don't know the exact reasons why it worked...  suffice to say, don't do it unless the benefits are overwhelming or reengineering is a vital necessity)note that having 2 teams; one working on the old, and one on the new never works in my experience.  the new people think they can do better than the old ones leading to arrogance and a lack of understanding of the complexities of the previous system.  plus, the old team gets jealous and justifiably resentful.  very bad karma.Andrew yes, rewriting is a huge risk.  the problems of the "big rewrite" are also related to the dangers of Second System Syndrome (Brooks) where the 2nd system is designed to solve all the problems of the 1st, but ends up becoming overengineered and never delivered.(however, sometimes (rarely), a rewrite makes sense.  i’ve seen it work to perfection in a tiny number of cases, but i don’t know the exact reasons why it worked…  suffice to say, don’t do it unless the benefits are overwhelming or reengineering is a vital necessity)note that having 2 teams; one working on the old, and one on the new never works in my experience.  the new people think they can do better than the old ones leading to arrogance and a lack of understanding of the complexities of the previous system.  plus, the old team gets jealous and justifiably resentful.  very bad karma.Andrew

]]> Door: arjan http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/comment-page-1/#comment-266 arjan Tue, 25 Sep 2007 20:54:56 +0000 http://jdevelopment.nl/java/is-it-possible-for-a-small-company-to-switch-their-development-language/#comment-266 <p>It's an interesting thought; rewriting a system from scratch in a 'better' language or with a better framework. The larger your code base is however, the less likely such a rewrite is to succeed. Even when the new technology is really vastly superior. </p> <br /><br /><p> </p> <p>I remember sending you an article about this subject a few years ago, when we planned a major rewrite of M4N (for the outsiders; this never happened). It may be illustrative to post the link to this article again: http://www.joelonsoftware.com/articles/fog0000000069.html<br /></p> <br /><br /><p> </p> <p>Joel Spolsky wrote about this some 7 years ago and he's still right.</p> <br /><br /><p> </p> <p>As you mention, with a large enough workforce a rewrite is sometimes an option though. Both Apple and Microsoft have been doing exactly that; a complete and total rewrite from scratch of both OS 9 and Windows 9x into resp. OS X and Windows NT. </p> It’s an interesting thought; rewriting a system from scratch in a ‘better’ language or with a better framework. The larger your code base is however, the less likely such a rewrite is to succeed. Even when the new technology is really vastly superior. 

 

I remember sending you an article about this subject a few years ago, when we planned a major rewrite of M4N (for the outsiders; this never happened). It may be illustrative to post the link to this article again: http://www.joelonsoftware.com/articles/fog0000000069.html

 

Joel Spolsky wrote about this some 7 years ago and he’s still right.

 

As you mention, with a large enough workforce a rewrite is sometimes an option though. Both Apple and Microsoft have been doing exactly that; a complete and total rewrite from scratch of both OS 9 and Windows 9x into resp. OS X and Windows NT. 

]]>