On Fri, Jun 21, 2013 at 7:38 PM, GS Chandy <email@example.com> wrote:
> Sorry about that. Let me see if I can make the point in future without > the shouting - however, I do notice that: > > i) none of them has ever taken back any of that and they had been shouting > their slogans out for quite a few years, I believe (long before I ever > arrived on the scene). >
That is not remarkable given the tenor of this list, which is defined by opposing camps with conflicting agendas. This is one of those lists where the so-called "math wars" get fought / debated / hashed out / shared. The rhetoric is what it is.
> > ii) But yet, I do observe that there are a few less fulminations being > expressed at Math-teach these days against the 'Education Mafia' and the > 'Schools of Education'. >
I would not be rushing to attribute much if any significance to such stats. The fog of war is dense.
> > This is really the heart of the matter in any societal system. GST did > not quite provide that. > >
GST is not over yet. An ongoing meme.
With me, like with Kenneth Boulding, it became more critical of and/or independent of Economics, while describing the same turf. The Henry George school in Economics (a school of thought, somewhat obscure) seems closer to my brand of GST in crediting sun energy for a steady flow of income, grant income in our books.
Humans revector solar income (includes organic produce) into channels of their own making (water wheels turning mills and so on, the water cycle being powered by sun energy and gravity). My website pages on GST have all these little diagrams with the sun pointing at the Earth and captions like "current == currency".
> While GST is indeed where several of Warfield's contributions to 'systems > science' arose from, I believe the crucial insight was absent there. For > one thing, GST was not a 'science' - it was a 'general theory'. The other > crucial insight, namely that we do need to enable people to work on and > resolve their own problems, at their own levels, was also (generally) > absent in GST. > > The crucial insight was certainly absent that, in systems, what we (as > individuals and as groups) really do need to do is simply to look at and > understand just how the factors in the respective systems may be > inter-related to the others (and to the purpose[s] of the system). >
Another author I write about and share the teachings of is this R. Buckminster Fuller, who references GST while picking up on the task of needing better integration among the disciplines.
He pioneers a new humanities language (readable as prose) that's so laced with rather precise uses of STEM terms, in ways consistent with the grain of current usage (e.g. "frequency"), as to gather momentum across a number of universities, starting in North Carolina. His kind of thinking also permeated the US military, with the hexapent dome in the Pentagon garden (1940s).
Both assets (a) and (c) below cover these topics from different angles:
(a) Divided Spheres (STEM primer, geometric, Popko) (b) Digital Mathematics (STEM textbook, Litvin & Litvin) (c) King of Infinite Space (a bio, Siobhan)
> For adequate 'understanding of the system', the specific and crucial > relationship simply has to be "CONTRIBUTES TO" (its 'negative', "HINDERS" > is also relevant). > > The'CPM scheduling' people had since the 1950s I believe been promoting > "PRECEDES" as the relationship to look at, clearly not realising that in > any unknown system, we simply cannot come to understand the precedence of > Events and Milestones in the system till we gather some prior needed > understanding about it - and this is available to us by trying to find out > how things may "CONTRIBUTE TO" each other. > > (Of course, CPM scheduling did not actually look at 'systems' explicitly, > though the systems are indeed, I believe, implicit there. The CPM people > clearly needed exposure to GST, which seems to have been absent in their > considerations. Robert Hansen is an instance of a person who got himself > seriously 'hung up' on "PRECEDES"). > >
A lot of this thinking has since been superseded by those designing algorithms for parallel processors. The need to think precisely about concurrency in various walks of life has fed back into GST, as it has into other disciplines.
> Warfield also perceived (right to begin with) that the specific > relationship that we need to look at in systems is "CONTRIBUTES TO". When > we come to understand the "CONTRIBUTIONS" of various system factors to each > other (and to the purpose[s] of the system, we may then begin to understand > the system - and with some understanding we may be able to work effectively > in and on it. > > > >One of these systems is TDD (test driven > > development) a branch of Agile. You let one group write tests for the > other and then switch. > > > I've seen Agile and TDD. (Though I'm not an expert, by any means). > Useful approach; I want to do something with Agile. However, I believe > the understanding that THE crucial relationship in systems is > "CONTRIBUTION" is absent (or, at least, it's not handled explicitly > enough). In any case, I don't believe either Agile or TDD will enable > anyone, at any level, to identify an issue or problem and work on it > starting with their currently available ideas. Both are clearly approaches > for specialists and 'experts' - but we need an approach that enables > non-specialists, 'non-experts' to work effectively on resolving issues and > problems. > > >
You're still a proponent of the all-uppercase keyword I see ("CONTRIBUTION"). I'm more from the e.e. cummings side of the fence, the unix world, with everything lowercase, almost.
Management and software engineering go hand in hand. Developing a STEM curriculum without serious consideration of the cyber tools and toys just leaves a lot of serious choices to others.
I encourage school faculties to advocate for their own schools, as a place to develop their own unique approaches.
Polytechnical schools should manage their own servers at some level, because it's what they teach, what they profess to know, just as ag schools should grow some of their own food.
Anyway, the CONTRIBUTION of the sun, a nearby star, to the planetary economy, is not to be overlooked and text books which do commit this omission are a curious genre, a layer in intellectual archeology coincident with a dark age in human thought.
> Well, yes, I recall from my very early 'Boy Scout' days, the very useful > character traits and skills (including the need for cooperation between > individuals along with 'some' competition) that the movement seeks to build > - in many ways quite successfully. (Of course, the 'scout movement' in > India must have developed rather differently from how it did in its nation > of origin [Britain] and I imagine it must have developed quite differently > in the US as well. I'm not adequately aware about any of this to comment - > except that I would believe that the underlying philosophy is indeed most > useful for all individuals in society. > > >
Boy Scout movements were amenable to hosting "nationalism", which is already ritualistic, so you get a lot of flag stuff in US scouting. At the recent Eagle Scout honoring ceremony I attended, the US national flag was presented as a gift to both boys receiving the status of Eagle, a top rank, along with a copy of 'The Peoples History' by Howard Zinn, an interesting synergy, perhaps symptomatic of a new synthesis within the dialectic -- a process in the Zeitgeist.
> > Software engineering is helping managers with many > > difficult tasks. The > > importance of version control with formal branching > > and merging is being > > recognized by the legal profession and I think before > > long the > > Congressional Record might find itself on Github or > > one of those (probably > > something more customized for legislation). > > > It is, indeed (helping managers with extremely difficult tasks). However > 'software engineering' as it stands is, I believe, somewhat deficient in > that it does not adequately inculcate a 'problem-solving approach' in its > practitioners. I confronted this problem when I tried to initiate > development of the OPMS software. The software people just were not able > to understand how to create and develop the software. As I'm not a > software engineer myself, we faced some difficulties - till we all learned > that it had to be handled as a problem outside 'software engineering' (to > begin with, at least). >
Management finally embraced the coding world when it realized it was wrestling with the wrong stereotype: they saw geeks as socially inept solitary types who retreated into windowless basements to pursue their asocial activities, sometimes returning to the surface with miracle "killer apps" that could be great sources of pure profit.
Then the light dawned: coding is often an intensely social activity with input from others coming in through chat windows, version control sites, emails, live streaming. You also sit on couches and code together. You geek out in smallish pods. The donuts and pizza are real, as is the beer. But you need to stay sharp so it may be more coffee or... (back to stereotypes) Jolt Cola and Red Bull.
The light came on with the advent of Linux, which took the world by storm -- clearly not a solo project. Apparently those geeks weren't being asocial in those basements, they were sharing the Internet.
Many spectators following the "dot com bomb" assumed that was a blip in the 1980s and 1990s, as if Linux had since gone away. But what happened instead is a more mature management stopped thinking in terms of get-rich-quick stupid pet trick schemes (though these still abound) and embraced the technology more for what it was, here to stay.
The discipline of TDD helped many companies invest in a style of code growth that permitted continuous testing with immediate notice of breakage when developing new features, a style less prone to bottleneck compared with some guy in the back room, the only one who "understands" a vast code pile.
> (However, what IS interesting is that, at that point when ILW shut up > shop, it happened to be at the very bottom of the 'dot-com bust' - but yet > ALL the members of the ILW software team were able to land themselves > excellent jobs - because, by this time, they had indeed become "very > effective s/w engineers"!! (That was their original Mission - and it served > them well). > > >
It's a joy to managers to come upon a subculture that has already trained itself in working together. The GNU project was what was behind Linux: the set of tools needed to write an operating system: emacs, gcc etc..
A challenge though was these geeks also had developed loyalties and didn't want to buy into an older design for intellectual property that would be at the cost of collaborative sharing. A system of "copylefts" (a form of copyrighting) was invented to keep the older set of reflexes at bay.
This strategy of "world domination" (retaining access to one's tools, retaining mastery) has paid off handsomely. Instead of trying to "beat" Linux, IBM jumped on board. Shared public knowledge, like mathematics and science itself, means shared skills and shared literacy, and therefore collaborative capability.
If you lock away the tools for a tiny group of elite select or pre-ordained, you create intolerable bottle-necks for yourself while everyone else works around you, leaving you in the dust.
> Of course. Software engineering (and developments from it) has been > responsible for a huge transformation in a great many aspects of our lives. > However, as we have realised in India, that is not enough at all: just > now, major parts of North India have been suffering from a 'Himalayan > tsunami' so to speak - for which we were ENTIRELY unprepared in ALL > respects. It's clear that the need for effective 'problem solving' is > somewhat more fundamental (arises from a more fundamental human need) than > 'software engineering'. It really is a 'habit of mind', I claim - and we > do not have enough of that at all in societies anywhere. > > GSC >
Whereas I'm claiming that geek cultures growing up around the evolution of the Internet have pioneered new collaboration skills that spill over, outside just the activity of writing code.
These same people participate in self government and on standards committees. They engage in peer review. They blend in and through academia. They are helping us redesign STEM education to include more of these 'lessons learned'.
True, we need to continue evolving and maturing our management practices.
I'm not saying we have reached some kind of pinnacle or final apex.
I'm just suggesting that GST is alive and well and continues to morph with each generation of contribution.