-------- Prvotno sporočilo -------- Datum: Tue, 31 Jan 2012 07:54:58 -0600 Od: Peter Hunsberger peter.hunsberger@gmail.com
With all due respect to the experience of everyone here, people really need to give up on this naive belief that Smalltalk development is any more efficient than development in any other language. The simple fact is that within the Smalltalk community a large portion of the developers have been using the tools for a long time and are very good at using them. Throw them at another environment and they are not as efficient. However, if you take new developers and throw them at a Smalltalk project it takes longer to get them up to speed than throwing them at a Java project simply because of the fact that Smalltalk is not as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so I've seen both sides of this issue for a long time, so let me related some anecdotal experience:
I'm currently working on a Smalltalk project that has about about 50 man years of effort in it over 10 years. Prior to this I worked on a Java and XSLt project that had about the same effort over the same period. Both have web based GUI's with a fair amount of JavaScript and the usual HTML crud and use a relational DB back end (SQL server and Oracle respectively). The Smalltalk project has had a mix of very experienced Smalltalk developers and inexperienced ones. The Java project was mainly junior and intermediate experience devs. I'd say the overall architecture and design was about equivalent; very different, but equally well done and comprehensive. The projects are very similar in concept and execution. The Java project had about twice as many function points (some pretty major) implemented and four times as many use cases supported at the point I switched to the Smalltalk project. For the most part this has little to do with the language itself. Rather, it is mainly, the supporting infrastructure that one is able to draw on in Java projects and this includes Eclipse, Git, etc. Open Source projects also played a big part of this, in the Java world one can pull in large chunks of functionality at very low cost (eg. XSLt 2.0 processors and pipelines, Spring, Hadoop, you name it) that are just not quite matched in the Smalltalk world. You can often get close, but it seems that there is always something missing, if only because the teams supporting the Smalltalk projects are often much smaller and just can't quite keep up with the every changing specs and requirements.
Bottom line, don't kid yourself that there is any inherent advantage in using Smalltalk development over any other language. It is faster for experienced devs in small projects, but if you've got to pull a team together from scratch for some medium to large complexity enterprise scale project it is probably not going to fair as well.
Now onto the main question posed here....
I have also worked on a successful 200 man year project (C and C++ in this case), which broke down to a little less than 100 people over a little more than 2 years. This was in the telecom world and involved many main frame billing interfaces and switching equipment interfaces, all very mission critical. In this case about 60% of the team was heads down developers. The rest of it was dedicated testers, tech writers, business analysts, project managers and managers. Here again the supporting infrastructure played an important role. Business analysts could write up use cases that got stored in a repository (a proprietary system) that could be used to generate test case stubs and documentation stubs. The development team tracked progress and bug reports in the same repository and source code version control was tied to the repository. End user documentation was stored in the repository and version controlled. It was simple to know what was going on anywhere in the project and to know where the problems were and what code did what and to see the entire life cycle of any portion of the code base from customer requirement to final deliverable. I know of no support infrastructure that even comes close in the Smalltalk world and would consider it madness to even consider taking on such a project using Smalltalk.
Peter Hunsberger
On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont <laurent.laffont@gmail.com mailto:laurent.laffont@gmail.com> wrote:
200 developers on a project ? Scaring ..... They should use another technology than Java to go under 50 developers. They will save a lot of money :)
Laurent
2012/1/28 Janko Mivšek <janko.mivsek@eranova.si mailto:janko.mivsek@eranova.si>
Hi guys,
Ralph Johnson in his InfoQ interview made an interesting observation:
2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... "
Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)?
Are we really not able to scale to bigger projects/systems because of that?
Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...
[1] http://www.infoq.com/interviews/johnson-armstrong-oop
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Interestingly enough, I worked on a telecom billing system with more than 100 Smalltalk developers back in the mid 90's. As you might expect, the problems we ran into had:
-- nothing to do with Smalltalk -- nothing to do with the SCM tools (Envy, at the time)
-- Everything to do with process.
At that same telecom outfit, they tried migrating from Smalltalk to Java at least 3 times over the course of the next decade, and they failed each time. Why? Because with Smalltalk, the process didn't quite kill off all forward progress (it came close, but never got there). Using a less productive tool (and Java in the mid 90's was a less productive one), they failed - <due to their processes>
While tools in general have improved, staff politics haven't moved much. Show me a 200 person project, and I'd bet very good money that I'll see a death march failing ugly due to nasty politics and a stifling process.
On Jan 31, 2012, at 1:19 PM, Janko Mivšek wrote:
-------- Prvotno sporočilo -------- Datum: Tue, 31 Jan 2012 07:54:58 -0600 Od: Peter Hunsberger peter.hunsberger@gmail.com
With all due respect to the experience of everyone here, people really need to give up on this naive belief that Smalltalk development is any more efficient than development in any other language. The simple fact is that within the Smalltalk community a large portion of the developers have been using the tools for a long time and are very good at using them. Throw them at another environment and they are not as efficient. However, if you take new developers and throw them at a Smalltalk project it takes longer to get them up to speed than throwing them at a Java project simply because of the fact that Smalltalk is not as ubiquitous. I switched to Java back when IBM dropped Smalltalk, so I've seen both sides of this issue for a long time, so let me related some anecdotal experience:
I'm currently working on a Smalltalk project that has about about 50 man years of effort in it over 10 years. Prior to this I worked on a Java and XSLt project that had about the same effort over the same period. Both have web based GUI's with a fair amount of JavaScript and the usual HTML crud and use a relational DB back end (SQL server and Oracle respectively). The Smalltalk project has had a mix of very experienced Smalltalk developers and inexperienced ones. The Java project was mainly junior and intermediate experience devs. I'd say the overall architecture and design was about equivalent; very different, but equally well done and comprehensive. The projects are very similar in concept and execution. The Java project had about twice as many function points (some pretty major) implemented and four times as many use cases supported at the point I switched to the Smalltalk project. For the most part this has little to do with the language itself. Rather, it is mainly, the supporting infrastructure that one is able to draw on in Java projects and this includes Eclipse, Git, etc. Open Source projects also played a big part of this, in the Java world one can pull in large chunks of functionality at very low cost (eg. XSLt 2.0 processors and pipelines, Spring, Hadoop, you name it) that are just not quite matched in the Smalltalk world. You can often get close, but it seems that there is always something missing, if only because the teams supporting the Smalltalk projects are often much smaller and just can't quite keep up with the every changing specs and requirements.
Bottom line, don't kid yourself that there is any inherent advantage in using Smalltalk development over any other language. It is faster for experienced devs in small projects, but if you've got to pull a team together from scratch for some medium to large complexity enterprise scale project it is probably not going to fair as well.
Now onto the main question posed here....
I have also worked on a successful 200 man year project (C and C++ in this case), which broke down to a little less than 100 people over a little more than 2 years. This was in the telecom world and involved many main frame billing interfaces and switching equipment interfaces, all very mission critical. In this case about 60% of the team was heads down developers. The rest of it was dedicated testers, tech writers, business analysts, project managers and managers. Here again the supporting infrastructure played an important role. Business analysts could write up use cases that got stored in a repository (a proprietary system) that could be used to generate test case stubs and documentation stubs. The development team tracked progress and bug reports in the same repository and source code version control was tied to the repository. End user documentation was stored in the repository and version controlled. It was simple to know what was going on anywhere in the project and to know where the problems were and what code did what and to see the entire life cycle of any portion of the code base from customer requirement to final deliverable. I know of no support infrastructure that even comes close in the Smalltalk world and would consider it madness to even consider taking on such a project using Smalltalk.
Peter Hunsberger
On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont <laurent.laffont@gmail.com mailto:laurent.laffont@gmail.com> wrote:
200 developers on a project ? Scaring ..... They should use another technology than Java to go under 50 developers. They will save a lot of money :)
Laurent
2012/1/28 Janko Mivšek <janko.mivsek@eranova.si mailto:janko.mivsek@eranova.si>
Hi guys, Ralph Johnson in his InfoQ interview made an interesting observation: 2:55 minute: "Smalltalk made an fundamental error ... image ... you can build something with 4-5 people what 50 people can build in Java, but if you take 200 people in Java ... it is really designed for small systems ... " Are we because of the image really destined for relatively small projects and small systems (of Java 50 people project size)? Are we really not able to scale to bigger projects/systems because of that? Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still... [1] http://www.infoq.com/interviews/johnson-armstrong-oop Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si<Pripet del sporočila.txt>
James Robertson http://www.jarober.com jarober@gmail.com
squeak-dev@lists.squeakfoundation.org
-
James Robertson -
Janko Mivšek