Gartner on Assessing the Age of Software Languages and Tools
in [Cobol]
|
Prev: MicroFocus Java
Next: MicroFocus Java
From: Anonymous on 15 Jun 2008 08:44 In article <g30t23030m3(a)news3.newsguy.com>, Michael Wojcik <mwojcik(a)newsguy.com> wrote: [snip] >Many of the programmers I encounter, in person and online, are pretty >content with the way things are - even when that means most of their >efforts go to fixing bugs that should never have been introduced in >the first place, even when it means constantly reinventing the wheel >and doing things the hard way. > >I think that's true of the practitioners of many crafts, perhaps of >all of them; it's likely a consequence of human nature, of the fact >that enthusiasm is bounded and we don't all find ourselves doing >things we really enjoy, that some people feel a need to improve and >others are content as they are. Hmmmmm... something like this was said before... let's see... ahhh... from <http://groups.google.com/group/alt.cobol/msg/744d356edb64c787?dmode=source> --begin quoted text: >I've never done contract work myself, but we've used about a dozen or so >contracters at my company. There have only been three out of the bunch that >could do what they said they could in the interviews. I would say that you've been lucky; my experience has been that in *any* given profession one out of ten has a real 'touch' for it... everyone else is faking and praying they don't get caught. 3/12 give you 25%... not bad at all. --end quoted text DD
From: Robert on 15 Jun 2008 13:17 On Sun, 15 Jun 2008 12:44:30 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <g30t23030m3(a)news3.newsguy.com>, >Michael Wojcik <mwojcik(a)newsguy.com> wrote: > >[snip] > >>Many of the programmers I encounter, in person and online, are pretty >>content with the way things are - even when that means most of their >>efforts go to fixing bugs that should never have been introduced in >>the first place, even when it means constantly reinventing the wheel >>and doing things the hard way. >> >>I think that's true of the practitioners of many crafts, perhaps of >>all of them; it's likely a consequence of human nature, of the fact >>that enthusiasm is bounded and we don't all find ourselves doing >>things we really enjoy, that some people feel a need to improve and >>others are content as they are. > >Hmmmmm... something like this was said before... let's see... ahhh... from ><http://groups.google.com/group/alt.cobol/msg/744d356edb64c787?dmode=source> > >--begin quoted text: > >>I've never done contract work myself, but we've used about a dozen or so >>contracters at my company. There have only been three out of the bunch that >>could do what they said they could in the interviews. > >I would say that you've been lucky; my experience has been that in *any* >given profession one out of ten has a real 'touch' for it... everyone else >is faking and praying they don't get caught. 3/12 give you 25%... not bad >at all. Worse, the fakers make house rules against real programming, so they won't look bad by comparison. Inferior work becomes the shop standard. During interviews, they try to screen out candidates who are too competent. Outsourcing is the easiest way to change the IT culture. Some companies try to do it by changing the programming language.
From: Anonymous on 15 Jun 2008 17:47 In article <8jia545ofek817inr2ce61rbrpt6i8g0gi(a)4ax.com>, Robert <no(a)e.mail> wrote: >On Sun, 15 Jun 2008 12:44:30 +0000 (UTC), docdwarf(a)panix.com () wrote: [snip] >>Hmmmmm... something like this was said before... let's see... ahhh... from >><http://groups.google.com/group/alt.cobol/msg/744d356edb64c787?dmode=source> >> >>--begin quoted text: >> >>>I've never done contract work myself, but we've used about a dozen or so >>>contracters at my company. There have only been three out of the bunch that >>>could do what they said they could in the interviews. >> >>I would say that you've been lucky; my experience has been that in *any* >>given profession one out of ten has a real 'touch' for it... everyone else >>is faking and praying they don't get caught. 3/12 give you 25%... not bad >>at all. > >Worse, the fakers make house rules against real programming, so they >won't look bad by >comparison. What part of '*any* given profession' (emphasis original) is limited to programming, Mr Wagner? Another entry in the 'I Can Document That From A Decade Back' from <http://groups.google.com/group/comp.software.year-2000/msg/50fe23475779d7e7?dmode=source> --begin quoted text: A while back I developed the theory of Gresham's Law of Management, which is... just that, Gresham's Law... applied to a managerial structure. --end quoted text .... and from <http://groups.google.com/group/comp.software.year-2000/msg/fbde2cf46db59b67?dmode=source> --begin quoted text I do not know how long he has been with the organisation but he may be perfectly suited to survival within the organisation; even if he were to be replaced with a Competent Manager one might a demonstration of Gresham's Law... Bad Management Drives Out The Good. --end quoted text DD
From: Howard Brazee on 16 Jun 2008 10:01 On Fri, 13 Jun 2008 20:09:51 -0500, Robert <no(a)e.mail> wrote: > >Managers are conservative, not developers. The same managers imposed waterfall to retard >change. They aren't doing that to retard change, they are using a methodology that they understand so that they can keep control. It often has the effect of retarding change, but it is better to understand their motivations.
From: klshafer on 16 Jun 2008 16:52
On Jun 16, 10:01 am, Howard Brazee <how...(a)brazee.net> wrote: > On Fri, 13 Jun 2008 20:09:51 -0500, Robert <n...(a)e.mail> wrote: > > >Managers are conservative, not developers. The same managers imposed waterfall to retard > >change. > > They aren't doing that to retard change, they are using a methodology > that they understand so that they can keep control. It often has the > effect of retarding change, but it is better to understand their > motivations. Those are very close to my sentiments, Mr. Brazee, which I arrived at a few years back, by asking (myself) the following question: "Just why is it, that in the face of supposedly overwhelming evidence for the inferiority of Waterfall, inn either its "vulgarized" (staircase, without feedback loops) or Royce-ian ("true" Waterfall, with feedback loops) forms, and evidence _for_ the "superiority" of other lifecycle "models", that Waterfall is _still_ so prevalent?" The answer that I gradually came to was "there is something else going on" and "it (Waterfall) _must_ fill some need that is difficult for me (us) to see." But I will take this one more small step forward, cautioning everyone that I am not quite ready to "defend" this "contention", for there are Other Threads More Worthy for Me (better fitting with my "puzzle"), but here goes anyway - It may be better (i.e. greater likelihood of project success) to have a sub-optimal model / methodology that everyone can understand and come to agree with, than to have an optimal model / methodology that does not have the same "mindshare" in the organization, and which can be divisive. This type of "mindsharing" I extend to any number of aspects in the team culture, such as business knowledge (subject matter expertise), technical knowledge, values, work ethic, and so on. The "need for control" and the ability to "understand their motivations" are a couple of important dimensions of Intersection that Mr. Brazee has cited for us. All other things being equal (OK, and I know that they never are), I believe a certain threshhold of "intersection" is important, even necessary, for project success. And it can often "trump" many other things. Rather than ask, "Why do many projects fail?", one can also ask, "Why, in the face of so many things done so wrongly, do so many projects _succeed_? (That is, succeed in _some_ important fashion)?" The answer, in part, is ... Intersection. Ken |