Smalltalk for small projects only?
Locked
Re: Smalltalk for small projects only?
 
|
Dear Janko,
(tried to send this to Pharo and squeak mailing lists as well as well as vwnc and you - got a hiccough; trying again just to vwnc and you). The largest Smalltalk project I've experienced was Kapital. They were approaching 70 developers in 4 locations in 2005 and IIUC are larger now. They use an in-house process based on Envy. Frequent rebuilding of images is forced by aging of Envy repositories, properly committed stuff being copied over. Thus developers are obliged to use correct process or lose code. I described the process briefly in a secondary talk (not my main one) at ESUG 2004, and Jan Monclair gave more recent info at ESUG 2008 and ESUG 2009 (see my reports on the ESUG website). A developer I knew there had practical experience of a rival's attempt to replicate their achievement in Java, using comparable resources, that crashed and burned. I've worked in two teams of 15 - 20 developers (one on a single site, one at two sites), each of which were verifiably matching systems maintained by ~100 developers in rivals. These were both in the insurance domain. In one of these, Envy-based, each developer rebuilt their image each day - the process took quite a few minutes but was valuable. In the other, images were eternal (yes, I do mean that!); it would take a long time to describe their process and even longer to convince readers that, contrary to what I at first thought and what most of you will think, it was a viable development process. All the other Smalltalk teams I've worked in, prior to coming to Cincom, were in single figures and used Store or Envy. One of them was verifiably rivalling a sytem of 10s of people in another language. Conclusions: 1) As your Smalltalk project gets large, you will need to put process and tools in place on top of what Envy, or Store, or, as Dale says, Monticello and Metacello, give you out-of-the-box at the moment. (It is news to me if Java projects of 200 people do not find the same, but I defer to those with more - which means any - experience of being in a 200-person Java project to correct me if that is not so - or is less so in some important respect.) It would be good if Smalltalk projects that find themselves growing into this area could get a tool/add-on that conveyed existing experience and solutions instead of having to re-roll their own superstructure on existing tools. (In Cincom, we are attempting to use our own development-process and build-process-improvement work to achieve this.) 2) Combining Kapital experience with the ratio one can justify between 'Smalltalk developers needed to do' and 'Java developers needed to do', persuades me that there is no limit on the complexity of problem Smalltalk can attack relative to its rivals. 3) I agree with Dale that making the minumum image smaller is the way to go. (Again, we wish to do this in VW; as always, such efforts progress slowly in background while we meet immediate requirements.) Yours faithfully Niall Ross _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Smalltalk for small projects only?
|
|
Dear Niall,
Thanks for comprehensive report, the biggest project reported so far. I forwarded it to Squeak and Pharo mailing lists. Has anyone data for other big Smalltalk projects/systems, like OOCL etc? Best regards Janko S, Niall Ross piše: > Dear Janko, > (tried to send this to Pharo and squeak mailing lists as well as well > as vwnc and you - got a hiccough; trying again just to vwnc and you). > > The largest Smalltalk project I've experienced was Kapital. They were > approaching 70 developers in 4 locations in 2005 and IIUC are larger > now. They use an in-house process based on Envy. Frequent rebuilding > of images is forced by aging of Envy repositories, properly committed > stuff being copied over. Thus developers are obliged to use correct > process or lose code. I described the process briefly in a secondary > talk (not my main one) at ESUG 2004, and Jan Monclair gave more recent > info at ESUG 2008 and ESUG 2009 (see my reports on the ESUG website). A > developer I knew there had practical experience of a rival's attempt to > replicate their achievement in Java, using comparable resources, that > crashed and burned. > > I've worked in two teams of 15 - 20 developers (one on a single site, > one at two sites), each of which were verifiably matching systems > maintained by ~100 developers in rivals. These were both in the > insurance domain. In one of these, Envy-based, each developer rebuilt > their image each day - the process took quite a few minutes but was > valuable. In the other, images were eternal (yes, I do mean that!); it > would take a long time to describe their process and even longer to > convince readers that, contrary to what I at first thought and what most > of you will think, it was a viable development process. > > All the other Smalltalk teams I've worked in, prior to coming to Cincom, > were in single figures and used Store or Envy. One of them was > verifiably rivalling a sytem of 10s of people in another language. > > Conclusions: > > 1) As your Smalltalk project gets large, you will need to put process > and tools in place on top of what Envy, or Store, or, as Dale says, > Monticello and Metacello, give you out-of-the-box at the moment. (It is > news to me if Java projects of 200 people do not find the same, but I > defer to those with more - which means any - experience of being in a > 200-person Java project to correct me if that is not so - or is less so > in some important respect.) > > It would be good if Smalltalk projects that find themselves growing into > this area could get a tool/add-on that conveyed existing experience and > solutions instead of having to re-roll their own superstructure on > existing tools. (In Cincom, we are attempting to use our own > development-process and build-process-improvement work to achieve this.) > > 2) Combining Kapital experience with the ratio one can justify between > 'Smalltalk developers needed to do' and 'Java developers needed to do', > persuades me that there is no limit on the complexity of problem > Smalltalk can attack relative to its rivals. > > 3) I agree with Dale that making the minumum image smaller is the way to > go. (Again, we wish to do this in VW; as always, such efforts progress > slowly in background while we meet immediate requirements.) > > Yours faithfully > Niall Ross > > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [Pharo-project] Smalltalk for small projects only?
|
|
In reply to this post by laurent laffont
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. On Sun, Jan 29, 2012 at 2:37 AM, laurent laffont <[hidden email]> 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 :) _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Smalltalk for small projects only?
|
|
In reply to this post by Janko Mivšek
2012/1/31 Janko Mivšek <[hidden email]>
Dear Niall, OOCL has 2 smalltalk projects The small one with 2,200 classes and 2 developers The larger one ranged from 20-50 developers (my guess), and currently has 24,000 classes. And the last time it was measured (a few years ago) we had around 8million lines of code. And my own personal $0.02 on productivity: One place I worked at as a contractor was a java shop. I was just learning java, so my skills at that time were lousy. We had a small project to do, and I managed to get 2 weeks of time from the local java expert. She came highly recommended by everyone, and after watching her work, she was in deed VERY good. After 2 weeks of struggle, we failed to finish the project. Afterwards, I sat down and did the project in visualworks ( from scratch) in 1 day. Experience matters, but using the right tool for the job is where its at. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
I knew we lost something: (was Smalltalk for small projects only?)
|
|
I don't have anything to add to the original thread, but I'm really enjoying following it. I hope someone can cross post it to the other relevant lists for me, that's kinda the whole point with my post.
Back in '97 when Squeak was in the ascendancy, some of its core team refused to have anything to do with the comp.lang.smalltalk usenet news group. There were understandable issues with the "one size fits everyone" traffic and spam there. So the squeak mailing list came into being. And then the VWNC mailing list. And the vwdev mailing list. Mailing lists for dolphin. And for VisualAge. GNU/St has its own mailing list. Seaside had enough traffic that they did their own. And I don't even know how many Pharo related lists there are now. I subscribe to the Squeak and Seaside lists, but I admit it's real rare that I pay attention to what's going on there. It's not that I don't want to or don't value the contributors there, it's just that I have a finite amount of time. Sadly, all of these lists contains fragments of discussions like the original, discussions where I think it really does behoove the whole Smalltalk community to be able to talk about them. But that was lost, and has never been replaced. I miss that. -- Travis Griggs Objologist "The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead." -- Ron Avitzur _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Peter Hunsberger
Ironically, I worked on a telecom project <in that domain> over a decade ago, with more people involved. Still in production, too.
On Jan 31, 2012, at 8:54 AM, Peter Hunsberger wrote: 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: James Robertson _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: I knew we lost something: (was Smalltalk for small projects only?)
|
|
In reply to this post by Travis Griggs-4
I don't like the fragmented discussion much either. I don't think cross-posting is the solution, but there are important topics that affect all Smalltalk dialects (e.g. how to make it easier to share code). Maybe we need another social networking tool to help :-)
Anyhow I stopped following these lists a few years ago but now I'm using Smalltalk again so it's good to know what's on people's minds. One of the main reasons I unsubscribed was the huge volume of unhelpful rants, but it's really difficult to quantify what those look like. E-mail filters might replace kill files, but the volume among all these lists is much smaller than it was in c.l.s. in the mid-90s. If we can keep the discussions from going off the rails for the usual reasons the mailing lists can be a great way to keep up on the latest changes. One important change is how much younger the Smalltalk dev community feels now (or maybe I feel older). I was really pleased to see that someone has managed to use git as a backend for Monticello. Now all we need is to have something similar for Store and Envy and we can all get moving in the same direction again! Cheers, Steve On Tue, Jan 31, 2012 at 10:28 AM, Travis Griggs <[hidden email]> wrote: I don't have anything to add to the original thread, but I'm really enjoying following it. I hope someone can cross post it to the other relevant lists for me, that's kinda the whole point with my post. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Travis Griggs-4
I too miss the days of c.l.s. One thing I had tried to do during my time at STIC was to have a Smalltalk 'slash dot' type of site, one where volunteers would post short descriptions with links to interesting threads in the various Smalltalk forums. Kind of what James does on his blog, but in a more organized way. It didn't fly. Plant Smalltalk is good for blogs, but I have not found a way to track all of the email lists. I simply do not have the time to follow them all, but I'm sure there good juicy bits of conversation out there. Personally, I'd like to see all the Smalltalk technical conversations move to
Stack Overflow, just to remind the rest of the world that we are still here (kinda like "Horton Hears a Who"). If you use the tags well it's an excellent site. Bob Nemec From: Travis Griggs <[hidden email]> To: VWNC NC <[hidden email]> Sent: Tuesday, January 31, 2012 1:28:45 PM Subject: [vwnc] I knew we lost something: (was Smalltalk for small projects only?) I don't have anything to add to the original thread, but I'm really enjoying following it. I hope someone can cross post it to the other relevant lists for me, that's kinda the whole point with my post. Back in '97 when Squeak was in the ascendancy, some of its core team refused to have anything to do with the comp.lang.smalltalk usenet news group. There were understandable issues with the "one size fits everyone" traffic and spam there. So the squeak mailing list came into being. And then the VWNC mailing list. And the vwdev mailing list. Mailing lists for dolphin. And for VisualAge. GNU/St has its own mailing list. Seaside had enough traffic that they did their own. And I don't even know how many Pharo related lists there are now. I subscribe to the Squeak and Seaside lists, but I admit it's real rare that I pay attention to what's going on there. It's not that I don't want to or don't value the contributors there, it's just that I have a finite amount of time. Sadly, all of these lists contains fragments of discussions like the original, discussions where I think it really does behoove the whole Smalltalk community to be able to talk about them. But that was lost, and has never been replaced. I miss that. -- Travis Griggs Objologist "The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead." -- Ron Avitzur _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Bob Nemec
|
Re: I knew we lost something: (was Smalltalk for small projects only?)
|
|
In reply to this post by Steve Wart-2
> If we can keep the discussions from going off the rails for the usual reasons the mailing lists can be a great way to keep up on the latest changes. One important change is how much younger the Smalltalk dev community feels now (or maybe I feel older). We spent actively the last 10 years producing books, teaching squeak/pharo, producing videos, making sure students can stay in the community by attending ESUG, supporting summer projects, building networks with teachers + seaside. Now there is a clear lack of movement in the US/Canada. The CS teachers moved to Java and we see it. ESUG is pushing pushing pushing. Stef _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [Pharo-project] Smalltalk for small projects only?
|
|
In reply to this post by jarober
Peter's point that "that there is [not] any inherent advantage in using Smalltalk development over any other language" is true by the criteria that he defined
to judged it. It is funny to see "Smalltalk efficiency" is being framed by a standard of high resource requirements, and that Java having twice as many function points and
four times as many cases for equivalent architecture and design was somehow a less relevant measure. One might observe that having such a wide variety of similar tools for a language like Java can indicate a limitation of reuse and extension. Smalltalk syntax
is less restrictive in how a framework can be reused and extended; that is a better criteria to judge efficiency of the language. "Smalltalk" is syntax and a basic class library; it is not defined by the availability of a vendor features. IBM failures are more relevant than a Smalltalk
failure. Large IBM projects of that era failed from Analysis Paralysis. A common goal was compliance with the latest buzz that IBM sold. There were a multitude of management styles in vogue at that time and all could be characterized as top-down management.
The "60% heads down developers" were given static designs that had a high and continuous cycle of costs as theory met reality. Large amounts of dumb and redundant code would be generated early. Code inertia and resistance to change would preclude opportunity
that is discovered later (like the ability to eliminate thousands of classes with a single reusable type). The result is as predictable as any top-down management style. All design problems were prevented from being fixed until they caused serious and recognizable
problems. The management styles of the time promised theoretical efficiencies of scale that had been determined from earlier failures with less malleable languages than Smalltalk. Effectiveness of these feudalistic management styles had yet to be recognized
as Dark Ages in the context of software development. Smalltalk does well when individual developers are given opportunity and responsibility, and to the extent that implementation is not restricted. Success with Smalltalk is about rewarding independent action
that furthers an objective goal. Management of a Smalltalk project is about providing healthy incentives while minimizing barriers to change. Top-down management (sold by IBM) was more to blame than "Smalltalk". Smalltalk is successfully used for large mission-critical projects that affect global markets. It doesn't take even a dozen Smalltalk developers to do that.
Smalltalk can be more efficient than other languages when a compatible management style is used. Smalltalk struggled through the Dark Ages of project management while more popular languages were developed outside of those conditions. Smalltalk is a victim
of timing, management, and vision. The more popular languages provide opportunity of market more so than opportunity of syntax. Languages have evolved to be increasingly more malleable like Smalltalk; that is recognition of an advantage that Smalltalk has
always had rather than proof that Smalltalk never was more efficient. Some people value opportunity of syntax that Smalltalk offers and have the vision to leverage that to a competitive advantage. Other people recognize that the
availability of resources and frameworks can also be leveraged as an advantage over Smalltalk. It is possible to find success or failure either way. Paul Baumann From: [hidden email] [mailto:[hidden email]]
On Behalf Of James Robertson Ironically, I worked on a telecom project <in that domain> over a decade ago, with more people involved. Still in production, too. On Jan 31, 2012, at 8:54 AM, Peter Hunsberger wrote:
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 <[hidden email]> 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 <[hidden email]> Hi guys,
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [Pharo-project] Smalltalk for small projects only?
|
|
Agile and Smalltalk go together well Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Paul Baumann Peter's point that "that there is [not] any inherent advantage in using Smalltalk development over any other language" is true by the criteria that he defined to judged it. It is funny to see "Smalltalk efficiency" is being framed by a standard of high resource requirements, and that Java having twice as many function points and four times as many cases for equivalent architecture and design was somehow a less relevant measure. One might observe that having such a wide variety of similar tools for a language like Java can indicate a limitation of reuse and extension. Smalltalk syntax is less restrictive in how a framework can be reused and extended; that is a better criteria to judge efficiency of the language. "Smalltalk" is syntax and a basic class library; it is not defined by the availability of a vendor features. IBM failures are more relevant than a Smalltalk failure. Large IBM projects of that era failed from Analysis Paralysis. A common goal was compliance with the latest buzz that IBM sold. There were a multitude of management styles in vogue at that time and all could be characterized as top-down management. The "60% heads down developers" were given static designs that had a high and continuous cycle of costs as theory met reality. Large amounts of dumb and redundant code would be generated early. Code inertia and resistance to change would preclude opportunity that is discovered later (like the ability to eliminate thousands of classes with a single reusable type). The result is as predictable as any top-down management style. All design problems were prevented from being fixed until they caused serious and recognizable problems. The management styles of the time promised theoretical efficiencies of scale that had been determined from earlier failures with less malleable languages than Smalltalk. Effectiveness of these feudalistic management styles had yet to be recognized as Dark Ages in the context of software development. Smalltalk does well when individual developers are given opportunity and responsibility, and to the extent that implementation is not restricted. Success with Smalltalk is about rewarding independent action that furthers an objective goal. Management of a Smalltalk project is about providing healthy incentives while minimizing barriers to change. Top-down management (sold by IBM) was more to blame than "Smalltalk". Smalltalk is successfully used for large mission-critical projects that affect global markets. It doesn't take even a dozen Smalltalk developers to do that. Smalltalk can be more efficient than other languages when a compatible management style is used. Smalltalk struggled through the Dark Ages of project management while more popular languages were developed outside of those conditions. Smalltalk is a victim of timing, management, and vision. The more popular languages provide opportunity of market more so than opportunity of syntax. Languages have evolved to be increasingly more malleable like Smalltalk; that is recognition of an advantage that Smalltalk has always had rather than proof that Smalltalk never was more efficient. Some people value opportunity of syntax that Smalltalk offers and have the vision to leverage that to a competitive advantage. Other people recognize that the availability of resources and frameworks can also be leveraged as an advantage over Smalltalk. It is possible to find success or failure either way. Paul Baumann From: [hidden email] [hidden email] On Behalf Of James Robertson Ironically, I worked on a telecom project <in that domain> over a decade ago, with more people involved. Still in production, too. On Jan 31, 2012, at 8:54 AM, Peter Hunsberger wrote: 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 <[hidden email]> 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 <[hidden email]> Hi guys,
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [Pharo-project] Smalltalk for small projects only?
|
|
In reply to this post by Peter Hunsberger
I don't think it is a
naive belief. There are actually differences between languages, and they
do matter in the success of projects. I think the widespread disdain
for Java in the development world at large is partly a recognition of
this.
This is just a bit of apocryphal and vaguely-remembered evidence, but I remember a discussion at a conference a few years back, and I think the participants were Alistair Cockburn and Martin Fowler. They were talking about "Design Starts" and successful completions of projects and the ratio between them as a metric. And were talking about various factors, but mentioned that in Smalltalk, though the number of starts was always low, the ratio of design starts to completions had been extraordinarily high. Equally apocryphal, I'm fond of saying that we have some large customers who are in the process of converting their applications from Smalltalk to another technology. Some of them have been doing so for many, many years.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Smalltalk for small projects only?
|
|
In reply to this post by Dennis smith-4
I am hoping that he meant multiple communicating images.
And do not think 4 or 10. Thinks hundreds. Each image could be small enough to run on one processor (remember: the hardware has scaled according to Moore's law, but Smalltalk has almost remained as small as it has always been), but in a massively scaled multiprocessor environment, we could keep up! We have invented objects. Languages like Erlang have tackled scalability, but we might tackle it a bit differently. And a lot closer to the OO paradigm. I remember Alan Kay once mentioning what he thought the internet would become: each object it's own IP adress, and all interacting we each other. But then someone invented the web... :-( On 29-01-12 00:55, Dennis Smith wrote: > When you say "divided", are you thinking of > - multiple communicating images?? > - multiple streams of development to be eventually combined into one > image?? > > > On 2012-01-28 18:51, Ralph Johnson wrote: >> This thread started with a reference to a comment I made some time >> ago. What I meant was that Smalltalk has no special advantages for >> large projects. It does have special advantages for small projects. >> But on large projects, the important problems are political, not >> technical. >> >> Smalltalk tends to have political problems; it is not one of the >> "standard" languages that you can easily justify to the board of >> directors, it can be hard to get good Smalltalkers in large numbers. >> So, it is not likely to be used on large projects. I don't think >> Smalltalk is necessarily any harder to use on a project with a lot of >> people, but projects with a lot of people are always dangerous and >> likely to fail. So, it is better to try to keep projects small, >> whether you are using Smalltalk or not. Smalltalk can help you keep >> it small. >> >> One thing that hasn't been discussed much is how to break a project >> into pieces. How often are project divided into a group of images >> instead of one giant image? I tend to see one giant image, and more >> and more I am thinking that is a mistake. >> >> -Ralph >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
rob.vcf (554 bytes)
Re: Smalltalk for small projects only?
|
|
In this context the thoughts of Alan Kay about what object orientation is are worthwhile reconsidering:
http://www.purl.org/stefan_ram/pub/doc_kay_oop_en -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Rob Vens Gesendet: Freitag, 3. Februar 2012 11:17 Cc: [hidden email] Betreff: Re: [vwnc] Smalltalk for small projects only? I am hoping that he meant multiple communicating images. And do not think 4 or 10. Thinks hundreds. Each image could be small enough to run on one processor (remember: the hardware has scaled according to Moore's law, but Smalltalk has almost remained as small as it has always been), but in a massively scaled multiprocessor environment, we could keep up! We have invented objects. Languages like Erlang have tackled scalability, but we might tackle it a bit differently. And a lot closer to the OO paradigm. I remember Alan Kay once mentioning what he thought the internet would become: each object it's own IP adress, and all interacting we each other. But then someone invented the web... :-( On 29-01-12 00:55, Dennis Smith wrote: > When you say "divided", are you thinking of > - multiple communicating images?? > - multiple streams of development to be eventually combined into > one image?? > > > On 2012-01-28 18:51, Ralph Johnson wrote: >> This thread started with a reference to a comment I made some time >> ago. What I meant was that Smalltalk has no special advantages for >> large projects. It does have special advantages for small projects. >> But on large projects, the important problems are political, not >> technical. >> >> Smalltalk tends to have political problems; it is not one of the >> "standard" languages that you can easily justify to the board of >> directors, it can be hard to get good Smalltalkers in large numbers. >> So, it is not likely to be used on large projects. I don't think >> Smalltalk is necessarily any harder to use on a project with a lot of >> people, but projects with a lot of people are always dangerous and >> likely to fail. So, it is better to try to keep projects small, >> whether you are using Smalltalk or not. Smalltalk can help you keep >> it small. >> >> One thing that hasn't been discussed much is how to break a project >> into pieces. How often are project divided into a group of images >> instead of one giant image? I tend to see one giant image, and more >> and more I am thinking that is a mistake. >> >> -Ralph >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Smalltalk for small projects only?
|
|
In reply to this post by Ralph Johnson
Dear Ralph,
>... on large projects, the important problems are political, not >technical. > >Smalltalk tends to have political problems; it is not one of the >"standard" languages that you can easily justify to the board of >directors, it can be hard to get good Smalltalkers in large numbers. > I note these are, in a logical sense, 'accidental' features of Smalltalk, not essential features. Many in this thread have been addressing whether Smalltalk has any 'essential' features that would cause problems in a large project: "Smalltalk is a problem for large projects" as against "Any less fashionable language, such as Smalltalk, is a problem for large projects." Such 'accidents' can of course be crucial to success or failure. However it is valid for anyone planning a project to distinguish true from perceived disadvantages, even accidental ones. Kapital was started before the brief period when Smalltalk was somewhat fashionable, and (AFAIK) continues now to find the people it needs without any special difficulty. If many large projects in Smalltalk were started simultaneously, there might be a shortage, but any one project - just _because_ it was choosing to be different - might have little difficulty in getting the team leaders it needed and recruiting/training the rest. Deciding that was so might need a realistic idea of the rate at which large projects can be grown. I think that many a project that imagines it has not the time for that realistic rate of growth will either go up like a rocket and come down like the stick, or else will quietly forget its earlier assumptions and actually grow at a realistic rate - in which case, the language decision was made on bad grounds. So I'm not disagreeing with your "not ... easily justify to the board of directors", just suggesting possible reasons anyone in that situation can use to make it easier. > >... projects with a lot of people are always dangerous and likely to > fail. So, it is better to try to keep projects small, whether you > are using Smalltalk or not. Smalltalk can help you keep it small. > A very valid point, and a good argument to use. Yours faithfully Niall Ross _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |