Kirby Urner posted Jun 21, 2013 10:42 PM (GSC's remarks interspersed): > > > i) I strongly believe that ideas like "PUT THE > EDUCAITON MAFIA IN JAIL" > > and "BLOW UP THE SCHOOLS OF EDUCATION" will NEVER > help us achieve anything > > positive in regard to the state of public school > education (or any > > education) in the US (or in India). (Even as > jokes, they are rather poor > > jokes). > > > > I agree and just seeing this all caps shouting > repeated over and over in > your postings is enough to turn me off reading them. > 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).
ii) But yet, I do observe that there are a few less such fulminations being expressed at Math-teach these days against the 'Education Mafia' and the 'Schools of Education'.
Perhaps there may now be some realistic efforts actually put in to improve the 'schools of education', to 'improve the education system' as a whole? These are, for sure, most desirable goals in any society (whether of the US or of India or of anywhere else). > > (My entire approach arises from the the basis of > development of a sizable > > number of 'OPMS models' for the Mission "To improve > the state of education" > > [in the USA; in India;wherever]. Brief information > about OPMS and the > > modeling processes in it is available at the > attachments to my post heading > > the thread "Democracy: how to achieve it" - > > > http://mathforum.org/kb/thread.jspa?threadID=2419536 > . My approach is > > developed largely from the seminal contributions to > systems science of the > > late John N. Warfield, about whom I have often > written here). > > > > GSC > > > > The management systems I look at use GST (general > systems theory) as their context. > The problems and issues we all face in various social systems demand something that people can learn to apply, themselves - at their own existing levels of competence (with the least possible amount of 'advanced study', 'expert knowledge' and so on and so forth).
This is really the heart of the matter in any societal system. GST did not quite provide that.
While GST is indeed where several of Warfield's contributions to 'systems science' arose from, I believe some crucial insights were absent there. For one thing, GST was not a 'science' - it was a 'general theory about systems'. One 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).
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").
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. > > Like imagine two camps of boy scouts. One proposes > challenges for the > other and then they switch roles. Challenges deemed > "over the top" are > disqualified by referees and each camp gets to choose > maybe three of ten. > But maybe they're all pretty difficult and > interesting. > > The goal is to help build the skills and virtues > associated with scouting > (there's a list) not to imbue the competition with > feelings of fear and > inferiority (although those feelings may come up and > need to be worked > through). > 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. > > 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).
The difficulties were resolved when I managed to identify an appropriate 'Mission' common to the underlying interests of all software engineers. I suggested that they should put aside their computers and just try, individually, to work out on the Mission:
"To become an effective (/leading) software designer within the next 1/3/5/... years"
- - no computer, no software engineering, no coding, no nothing except pencil and paper and their own ideas from their own 'mental models' in response to that Mission. (Using the OPMS approach).
As you might imagine, there was a fair amount of resistance from them to the idea that they had to put their beloved computers aside! However, we persisted; I'd spend about a half-hour each day with them individually, just looking at the expression of their ideas relative to that Mission; helping them construct, develop and interpret their models. (Later we started meeting in small groups of two and three).
Lo and behold, in less than two months, they came to me and informed me that they now knew just how to develop the OPMS software - and then they went ahead and did just that. The prototype OPMS software has been found to be pretty sound in practically all respects.
(I did seriously fail, however, in my aim of trying to get my co-directors in the company formed to develop and market the software to use the OPMS approach themselves, for their own organisational responsibilities - and the company [Interactive LogicWare, ILW] later foundered.
(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). > > SQL + NoSQL is helping the less advanced professions > live up to their ideal > of themselves more. When I take my Nissan to the > corner Jiffy Lube for an > oil change, they have a whole lot of history, and all > without oily fingers > pawing through paper files. Thanks to software > engineers. > > Kirby > 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.