Mapping (CoBOL) Methodologies to Problem Domains
in [Cobol]
|
From: klshafer on 22 Jan 2008 21:55 All - Haven't been here for a while due to personal demands, but now that I'm back, I wanted to put out an informal Call for Participation along the following lines. In another forum I participate in we discuss methodological approaches more than languages (eg. CMM vs. Agile). Here is the essence of a post I put out there, and I'm putting it in CLC to solicit the CoBOL angle, to wit, what methodologies are you using in your CoBOL efforts: structured analysis / structured design, object-oriented, custom, code-and-fix :-), whatever. CoBOL to "language-du-jour" converts' opinions also welcome (that's at least *you*, Mr. Pete Dashwood :-) ). I guess it's OK to do some follow up here within this thread in CLC, but seeing as how this is just a little bit off the usual beaten track of CLC, I don't want it to get "out of hand" (as if anything here ever does!) Anyway, here is a "copy and past" of what I posted elsewhere! All - Anonymous's last post got me thinking, and I reviewed my c:\ drive for some articles I had culled regarding this problem, which is namely, "What methodologies/methods should we apply to what domains of problems?" I have three seminal works by Robert Glass that are directly relevant here (you will need ACM and/or IEEE membership to get these, but I can help you): "Contemporary Application Domain Taxonomies" http://portal.acm.org/citation.cfm?id=625489 "Some Heresy Regarding Software Engineering" http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=1309657&isnumber=29063 "Matching Methodology to Problem Domain" http://portal.acm.org/citation.cfm?id=986228 In these works Glass makes it abundantly clear how **little** work has been done in this area, by either industry or academia, and so this might be an opportunity for some (relatively) groundbreaking work. Those interested in exploring this aspect independently of <CLC and other Forums>, please post here in this thread, or contact me offline at my e-mail address. The goal for this exploration should be initially modest (I have a fair amount of personal business to attend to in the short term, which limits my time), but could be on the order of accumulating enough "stuff" (viewpoints, rough "artifacts") to present a "Roundtable", "Birds of a Feather", "Panel", or simply "Gathering" at something like GLSEC (Great Lakes Software Excellence Conference), but certainly not so much as to qualify as a "seminar" or "workshop", let alone a "conference" :-). I think for the time being this effort would be organized as a simple cc: list for some occasional group e-mailings, and not yet anything more structured. But I'd like to get started on it by accumlating a list of interested parties? Any takers? Ken
From: Pete Dashwood on 22 Jan 2008 22:57 <klshafer(a)att.net> wrote in message news:519b9104-a107-4f9d-b341-781c2185da40(a)d4g2000prg.googlegroups.com... > All - > > Haven't been here for a while due to personal demands, but now that > I'm back, I wanted to put out an informal Call for Participation along > the following lines. In another forum I participate in we discuss > methodological approaches more than languages (eg. CMM vs. Agile). > Here is the essence of a post I put out there, and I'm putting it in > CLC to solicit the CoBOL angle, to wit, what methodologies are you > using in your CoBOL efforts: structured analysis / structured design, > object-oriented, custom, code-and-fix :-), whatever. CoBOL to > "language-du-jour" converts' opinions also welcome (that's at least > *you*, Mr. Pete Dashwood :-) ). I believe that any attempt at problem solution that is driven from a Language perspective will not be optimum, so looking for approaches taken with COBOL (as opposed to anything else) for me, is a non-starter. I apply the same problem solution approaches no matter WHAT language is in use. > > I guess it's OK to do some follow up here within this thread in CLC, > but seeing as how this is just a little bit off the usual beaten track > of CLC, I don't want it to get "out of hand" (as if anything here ever > does!) > > Anyway, here is a "copy and past" of what I posted elsewhere! > > All - > > Anonymous's last post got me thinking, and I reviewed my c:\ drive for > some articles I had culled regarding this problem, which is namely, > > "What methodologies/methods should we apply to what domains of > problems?" Pre-supposes that there ARE different domains of problem; in commercial computer programming this is arguable: "Get a solution implemented that costs as little as possible, takes as little time as possible, meets the Business requirements, and is comfortable for users to use." If you can manage to also minimise future maintenance and make the new system integrate nicely with current and foreseeable technical environments, that's a bonus...:-) > > I have three seminal works by Robert Glass that are directly relevant > here (you will need ACM and/or IEEE membership to get these, but I can > help you): > > "Contemporary Application Domain Taxonomies" > http://portal.acm.org/citation.cfm?id=625489 > > "Some Heresy Regarding Software Engineering" > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=1309657&isnumber=29063 > > "Matching Methodology to Problem Domain" > http://portal.acm.org/citation.cfm?id=986228 > > In these works Glass makes it abundantly clear how **little** work has > been done in this area, by either industry or academia, and so this > might be an opportunity for some (relatively) groundbreaking work. Glass should speak for himself. Personally, I've been researching, analysing, postulating, experimenting, and considering this for the last 43 years. I have arrived at some interesting conclusions which will be published in a forthcoming book that will be completed later this year. I can tell you this for nothing: 1. No single one of the current methodologies works to complete satisfaction (with the POSSIBLE exception of DSDM...) when applied by itself, alone. 2. There is a marked lack of imagination on the part of both Business Management and Technical Management when addressing this problem. 3. The main reason for software engineering failures is very bright technical people being poorly led by managers who secretly despise them, and have little or no understanding of what they do/need. (Point being: It isn't necessarily about Methodology...) 4. It IS possible to formulate a General Solution to commercial software engineering, that will solve more than 80% of the problems projects encounter. (However, doing so requires vision, imagination, and acceptance of change which most organisations are not capable of, or simply don't have.) This "general solution" is possible because, at least in the domain of commercial software solution engineering, there are the same (or very similar) "general problems" that manifest thermselves on every project, despite the fact that EVERY Management team believes THEY are unique and THEIR business is completely different from everyone else's. I think this myopia occurs because they are not capable of the pattern recognition that their tech staff do instinctively. I am postulating a completely different approach, but I don't want to spoil it by pre-announcing it here. I WILL say that it includes the best points of several currently successful methodologies, along with some quite innovative ideas, based on my own experience and what I've found to work. I can also say that it is as far divorced from Waterfall as it is possible to get :-) Amazingly, I have a track record of 20 years in PM without a failure (1 project was not completed due to international corporate politics, over which I had no control), yet I have NEVER implemented (completely) the standard approach required on any particular site. Had I done so, the project would have failed.:-) I believe the factors required for successful implementation are not easily identifiable or quantifiable and I address this in the book. Certainly some of them cannot be taught, but must be learned by observation and experience. It IS possible to raise awareness of them and suggest some approaches... > > Those interested in exploring this aspect independently of <CLC and > other Forums>, please post here in this thread, or contact me offline > at my e-mail address. The goal for this exploration should be > initially modest (I have a fair amount of personal business to attend > to in the short term, which limits my time), but could be on the order > of accumulating enough "stuff" (viewpoints, rough "artifacts") to > present a "Roundtable", "Birds of a Feather", "Panel", or simply > "Gathering" at something like GLSEC (Great Lakes Software Excellence > Conference), but certainly not so much as to qualify as a "seminar" or > "workshop", let alone a "conference" :-). > > I think for the time being this effort would be organized as a simple > cc: list for some occasional group e-mailings, and not yet anything > more structured. > > But I'd like to get started on it by accumlating a list of interested > parties? > > Any takers? Not at this stage, Ken. I believe it will be too dry and Academic to interest me, and I can't/won't contribute to a pissing contest about methodologies, none of which I believe to be perfect... :-) Nevertheless, I wish you luck with it :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 23 Jan 2008 05:36 In article <519b9104-a107-4f9d-b341-781c2185da40(a)d4g2000prg.googlegroups.com>, klshafer(a)att.net <klshafer(a)att.net> wrote: >All - > >Haven't been here for a while due to personal demands, but now that >I'm back, I wanted to put out an informal Call for Participation along >the following lines. In another forum I participate in we discuss >methodological approaches more than languages (eg. CMM vs. Agile). >Here is the essence of a post I put out there, and I'm putting it in >CLC to solicit the CoBOL angle, to wit, what methodologies are you >using in your CoBOL efforts: structured analysis / structured design, >object-oriented, custom, code-and-fix :-), whatever. I use, of course, whatever style fits into the code that already exists at the client's site... if a programmer expects something to occur in a certain place or way then I want to make sure I do my best not to add confusion. For example, if a program usually starts with something like: Procedure Division using LinkParms. Evaluate PassThrough When 1 Perform First-Calls Perform Edit-Data When 2 Perform Edit-data When Other Perform LinkParms-Corrupt End-Evaluate Perform Cleanup Goback. .... then it is rather unlikely for me to write PROCEDURE DIVISION USING LINKPARMS. PERFORM 0000-HOUSEKEEPING THRU 0000-EX. PERFORM 5000-MAINLINE THRU 5000-EX. PERFORM 9000-EOJ THRU 9000-EX. GOBACK. 0000-HOUSEKEEPING. MOVE LS-PASS-FLD TO WK-PASS-FLD. IF NOT FIRST-TIME-IN GO TO 0000-EX. .... et and cetera. If something just Isn't Working (certain things keep going wrong in certain ways) then I'll make my suggestions as to how I believe difficulties might be alleviated... but as long as what I do doesn't violate my own standards of Professional Ethics then, ultimately, I'll do what the person who signs my timesheets tells me to do; something about paying pipers and calling tunes. DD
From: Anonymous on 23 Jan 2008 08:35 In article <5vns9hF1ns38fU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: [snip] >This "general solution" is possible because, at least in the domain >of commercial software solution engineering, there are the same (or very >similar) "general problems" that manifest thermselves on every project, >despite the fact that EVERY Management team believes THEY are unique and >THEIR business is completely different from everyone else's. I think this >myopia occurs because they are not capable of the pattern recognition that >their tech staff do instinctively. Mr Dashwood, I'm not sure about pattern recognition and such... but I've read in a few texts that it is a very ancient and human phenomenom to consider one's Place and one's People to be special and superior to everything else; the (that-which-caused-creation) made the Human Beings and their Land of which We are part, etc. Given that as an almost species-level behavior the diffident sniff and 'NIH' (Not Invented Here) dismissal aimed at a new idea or process seems... downright Human, it does. DD
From: klshafer on 23 Jan 2008 12:18
On Jan 22, 10:57 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > > Not at this stage, Ken. I believe it will be too dry and Academic to > interest me, and I can't/won't contribute to a pissing contest about > methodologies, none of which I believe to be perfect... :-) > > Nevertheless, I wish you luck with it :-) > > Pete. Uhh, can you get me a pre-publication copy of your book? :-) Ken |