Call for a Professional Programmers' Association
-
Certifications are a scam that only benefits the people that are charging money for them. Anyone can get one. Like a college diploma. Your cited example of the 737 Max problem was NOT the fault of the programmers. They wrote the code to the specs, and Boeing knew IN ADVANCE that there might be a problem with their specs. They even had a workaround for pilots to perform in the event a problem cropped up. Boeing management's fault, not the coders.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I disagree that programmers are absolved. From a link by another (How the Boeing 737 Max Disaster Looks to a Software Developer - IEEE Spectrum[^] START QUOTE It is astounding that no one who wrote the MCAS software for the 737 Max seems even to have raised the possibility of using multiple inputs, including the opposite angle-of-attack sensor, in the computer’s determination of an impending stall. As a lifetime member of the software development fraternity, I don’t know what toxic combination of inexperience, hubris, or lack of cultural understanding led to this mistake. But I do know that it’s indicative of a much deeper problem. The people who wrote the code for the original MCAS system were obviously terribly far out of their league and did not know it. How can they implement a software fix, much less give us any comfort that the rest of the flight management software is reliable? END QUOTE
Gus Gustafson
-
I disagree that programmers are absolved. From a link by another (How the Boeing 737 Max Disaster Looks to a Software Developer - IEEE Spectrum[^] START QUOTE It is astounding that no one who wrote the MCAS software for the 737 Max seems even to have raised the possibility of using multiple inputs, including the opposite angle-of-attack sensor, in the computer’s determination of an impending stall. As a lifetime member of the software development fraternity, I don’t know what toxic combination of inexperience, hubris, or lack of cultural understanding led to this mistake. But I do know that it’s indicative of a much deeper problem. The people who wrote the code for the original MCAS system were obviously terribly far out of their league and did not know it. How can they implement a software fix, much less give us any comfort that the rest of the flight management software is reliable? END QUOTE
Gus Gustafson
- Most corporate coders are given a task to perform, and that is all they are to do, Many times, they have no contextual basis for the code they write beyond expected paramaters, and expected results. USAA (a big insurance company here in the US) is like this. Because they lack context, they couldn't possibly identify a potential issue. 1) Even if they were more aware, they could have said something to their immediate superior (or logged it in their bug tracking software), but the idea/observation was quashed/ignored somewhere along the management food chain. 2) Problems may have been cited, but management decided not to act due to costs. It's not a big leap to assume that management would scrub evidence that indicates this was the case, so saying it doesn't show up in the bug tracking/source controls logs doesn't mean squat. 3) Ultimately, the system engineer should have been included in the acceptance testing phase, and probably be the one to identify the problem - NOT the coders. 4) Even if the coders were "out of their league", how would the coders test something they don't fully understand? 5) What do you want to bet that it was the *engineers* that wrote this code? I woudln't EVER refer to an engineer as a "programmer". They simply aren't. The "hubris" lies with the engineers, not the programmers. If I was a programmer that had worked on that system, and they were trying to claim I was the reason for the flaw, and further, that I knew the actual truth, I'd be pretty vocal about placing the blame where it rightly belongs. Boeing is looking for scapegoats, and programmers are low man on the totem pole. If they thought they could get away with blaming the janitors, they certainly would try. In the end, the guy in charge of Boeing is ultimately responsible.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
- Most corporate coders are given a task to perform, and that is all they are to do, Many times, they have no contextual basis for the code they write beyond expected paramaters, and expected results. USAA (a big insurance company here in the US) is like this. Because they lack context, they couldn't possibly identify a potential issue. 1) Even if they were more aware, they could have said something to their immediate superior (or logged it in their bug tracking software), but the idea/observation was quashed/ignored somewhere along the management food chain. 2) Problems may have been cited, but management decided not to act due to costs. It's not a big leap to assume that management would scrub evidence that indicates this was the case, so saying it doesn't show up in the bug tracking/source controls logs doesn't mean squat. 3) Ultimately, the system engineer should have been included in the acceptance testing phase, and probably be the one to identify the problem - NOT the coders. 4) Even if the coders were "out of their league", how would the coders test something they don't fully understand? 5) What do you want to bet that it was the *engineers* that wrote this code? I woudln't EVER refer to an engineer as a "programmer". They simply aren't. The "hubris" lies with the engineers, not the programmers. If I was a programmer that had worked on that system, and they were trying to claim I was the reason for the flaw, and further, that I knew the actual truth, I'd be pretty vocal about placing the blame where it rightly belongs. Boeing is looking for scapegoats, and programmers are low man on the totem pole. If they thought they could get away with blaming the janitors, they certainly would try. In the end, the guy in charge of Boeing is ultimately responsible.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013If we are to change the scenario you rightly describe, we cannot justr wait until it happens. We must make it happen. With a strong organization, I think we can define the process by which software is developed. I'm not sure how (my job here is not to direct but rather to propose) but once organized the issues can be addressed. Your points are a sad commentary on today's state of programming. They're more reason to organize.
Gus Gustafson
-
If we are to change the scenario you rightly describe, we cannot justr wait until it happens. We must make it happen. With a strong organization, I think we can define the process by which software is developed. I'm not sure how (my job here is not to direct but rather to propose) but once organized the issues can be addressed. Your points are a sad commentary on today's state of programming. They're more reason to organize.
Gus Gustafson
Organizing programmers is NOT going to fix faulty management.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Organizing programmers is NOT going to fix faulty management.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I disagree. Faulty management should be addressed by the organization. Management training should be provided. And sanctions if companies do not cooperate. Remember Congressionally Charted?
Gus Gustafson
-
When I started programming for a major software services company in 1973, I was paid $12K per year. I received 10% pay raises every 6 months. Because I was cheap and good, my job was secure. In 1998, I was earning $103K per year. But when I left my then-current employer I also left all of my benefits: six weeks vacation, a retirement account, health benefits for my partner and myself, and most importantly a job. The reason for my departure was the need to reallocate discretionary funds to Bosnia training (I was a contractor for the US Army at the National Training Center). When I landed in a new job, I was paid $25K per year (my choice to get a job). By the time I finally left commercial programming, I was earning about $50K per year. Because of my life style, I didn't need savings: no kids, no college, no weddings, etc. I thought my whole salary was discretionary (with the exception of mortgages, automobile loan, etc.). I am not complaining about my foolishness. I have Social Security, Veterans benefits, an annuity, and a trust fund (the latter two established by my family who recognized my financial planning shortcomings). In a quick search, I turned up an Experian survey that suggests that I was not alone in the manner in which I spent money. The take-away: a professional organization for programmers may well have solved my financial planning problem. Not necessarily, but possibly.
Gus Gustafson
-
@Raddevus Hi, If there's one thing I am sure of, it's that I'd be proud if you thought I was in your community :omg: I consider some of the Quora groups, like [^], and [^], and various SIG groups at the ACM [^], to be virtual communities where you often find people sharing/discussing topics at higher levels of abstraction than specific OS's, languages, hardware. cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
BillWoodruff wrote:
If there's one thing I am sure of, it's that I'd be proud if you thought I was in your community
Well, I feel the same way about you. :-D There are a lot of great people here at CP and they always challenge me to think different. :thumbsup:
-
Only a fool counts on others to protect them against their own foolishness. If a professional society solved your problem, it would be by accident, not by design. It's not a good reason to found a professional society.
I believe you post is approaching incivility. I have so marked it.
Gus Gustafson
-
gggustafson wrote:
. When I was a member of the ANS X3J9 technical committee (Pascal) we were limited to a language update every five years.
And back then that worked because there wasn't as often a change in the industry. Now, this industry moves much faster and needs updates much more often.
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
I disagree that there is any "change" in the industry. Ive lived through wide variety of hardware platforms ranging from mobile devices to mainframe computers to PCs to specialized military hardware and microprocessors and a large number of development platforms. Except for read-in time, I find programming to be the same. By the way, X3's insistence on a five-cycle was to allow programmers to become knowledgeable of the current standard implementation. FYI, during my programming career COBOL was the most stable.
Gus Gustafson
-
I disagree that there is any "change" in the industry. Ive lived through wide variety of hardware platforms ranging from mobile devices to mainframe computers to PCs to specialized military hardware and microprocessors and a large number of development platforms. Except for read-in time, I find programming to be the same. By the way, X3's insistence on a five-cycle was to allow programmers to become knowledgeable of the current standard implementation. FYI, during my programming career COBOL was the most stable.
Gus Gustafson
gggustafson wrote:
I disagree that there is any "change" in the industry.
Computers are everywhere now. :doh:
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
-
gggustafson wrote:
I disagree that there is any "change" in the industry.
Computers are everywhere now. :doh:
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
So? So is programming all of them!
Gus Gustafson
-
So? So is programming all of them!
Gus Gustafson
The original point I responded to was about only updating programming languages every 5 years. Technology moved much slower back then and so it worked. It moves way too fast today to stay on a 5 year update schedule. Things have changed a ton!
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
-
Programming is the most intellectually stimulating activity that I have ever performed. It is not so much the making of things from nothing as it is the satisfaction that comes when I have created a thing of intellectual beauty. To me programming is a combination of art and science. And, in programming, technical competency goes hand in hand with technical currency. So that you understand from whence I come I would like to introduce you to what I have done during my career, and what I continue to do in a more relaxed environment: I wrote stand alone multi-threaded client/server systems; graphics software and effective user interfaces to complex scientific and engineering applications; real-time and embedded system software and firmware; and communications system software. I continue to be fluent in multiple computer programming languages (e.g., C#, C, Ada, FORTRAN, COBOL, and Pascal). I have programmed within Windows, UNIX, Linux, VxWorks, as well as others too old and long ago to mention. What bothers me about programming today is the number of people who claim to be programmers but who are not. These wannabes claim to be programmers but when you look at a wannabe's accomplishments, they usually include applications that are written in a macro language (such as VBA) and that are usually trivial and unfocused. We need a word to describe this class of people who are intelligent enough to pretend to program without actually programming. In many other career paths, they would be called apprentices. Let me define what I did in unambiguous terms. I was a professional production programmer who wrote computer software for money paid by someone who would probably not use the software. I firmly believe that programmers should be held accountable for their mistakes (witness the Boeing 737 Max disasters). I am convinced that the only solution to this problem is the certification of programmers by a vendor-independent organization. Although Code Project has indicated that it is opposed to such a certification organization, I believe that the arguments offered were specious. My question is simply "Doesn't the programmer who wrote the software that caused some type of catastrophe share the responsibility for the disaster?" It is for this reason that certification is required. Once such an organization is in place, companies that do not wish to share the blame for a software based disaster can hire a certified professional. The certified professional should then use certified journeymen and certified apprentices to d
Unionize, never. Professional organization, like ASME for mechanical engineers, or even like a PE license, yes.
-
The original point I responded to was about only updating programming languages every 5 years. Technology moved much slower back then and so it worked. It moves way too fast today to stay on a 5 year update schedule. Things have changed a ton!
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
The world in which programming occurs may change rapidly, but the art/science of programming does not. Consider COBOL. It hasn't changed in years. Yet most mainframe financial software (that drives most of the world's economy) is written in COBOL. If one accepts Dijkstra's writings, one must come to the conclusion that programming languages are tools, just like screw-drivers and pliers. Their worth is not how often they change but rather how well they were initially conceived. Of all the languages that I've used, Pascal was the cleanest. X3J9 did nothing but to formalize the User Manual and Report. Wirth made one error - you could not link modules together (the reason that Pascal could not compete with C). But look at C#. Releases almost yearly. How can a serious programmer keep up? I program using tried and true methods, not the latest fad. So as C# has "advanced" I have remained static knowing I can program everything I need with C# V3 and the Win 32 API. Thanks for your thoughts.
Gus Gustafson
-
I look forward to dinner with you ! :rolleyes:
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
why not?!! If you are in planning came in italy.. let me know. I'm living in Abruzzo, on the other side respect to Rome, on the Adriatico sea:thumbsup:
-
Programming is the most intellectually stimulating activity that I have ever performed. It is not so much the making of things from nothing as it is the satisfaction that comes when I have created a thing of intellectual beauty. To me programming is a combination of art and science. And, in programming, technical competency goes hand in hand with technical currency. So that you understand from whence I come I would like to introduce you to what I have done during my career, and what I continue to do in a more relaxed environment: I wrote stand alone multi-threaded client/server systems; graphics software and effective user interfaces to complex scientific and engineering applications; real-time and embedded system software and firmware; and communications system software. I continue to be fluent in multiple computer programming languages (e.g., C#, C, Ada, FORTRAN, COBOL, and Pascal). I have programmed within Windows, UNIX, Linux, VxWorks, as well as others too old and long ago to mention. What bothers me about programming today is the number of people who claim to be programmers but who are not. These wannabes claim to be programmers but when you look at a wannabe's accomplishments, they usually include applications that are written in a macro language (such as VBA) and that are usually trivial and unfocused. We need a word to describe this class of people who are intelligent enough to pretend to program without actually programming. In many other career paths, they would be called apprentices. Let me define what I did in unambiguous terms. I was a professional production programmer who wrote computer software for money paid by someone who would probably not use the software. I firmly believe that programmers should be held accountable for their mistakes (witness the Boeing 737 Max disasters). I am convinced that the only solution to this problem is the certification of programmers by a vendor-independent organization. Although Code Project has indicated that it is opposed to such a certification organization, I believe that the arguments offered were specious. My question is simply "Doesn't the programmer who wrote the software that caused some type of catastrophe share the responsibility for the disaster?" It is for this reason that certification is required. Once such an organization is in place, companies that do not wish to share the blame for a software based disaster can hire a certified professional. The certified professional should then use certified journeymen and certified apprentices to d
What about the ACM? The Association for Computing Machinery is about as professional as can be had.
-
What about the ACM? The Association for Computing Machinery is about as professional as can be had.
When I discovered the ACM in 1975, I was just beginning to learn that there was much more to programming than just design and coding. It seemed to me that the ACM was an organization that could help me improve my understanding of algorithms and architecture. I was so impressed that I recruited my peers and students to join the ACM. I had subscriptions to Communications, JACM, Reviews, Transactions, and joined the special interest groups SIGGRAPH, SIGMOD, SIGPLAN, SIGSIM, and SIGSOFT. I ended up with more than 25 boxes of publication that I touted around from job to job. There were a few notable exceptions: Boyer Moore A fast string searching algorithm and Vitter's Implementations for Coalesced Hashing. But it seemed that ACM was aiming solely at academia rather than including programmers-in-the-wild. The ACM offers little to its members in the way the proposed organization would. So although I agree that the ACM was once (in 1975 - 1998) an organization that programmers should join, I don't think that it would perform the services I suggest. Note too that I proposed such an organization to ACM and was advised it was not interested!
Gus Gustafson
-
- Most corporate coders are given a task to perform, and that is all they are to do, Many times, they have no contextual basis for the code they write beyond expected paramaters, and expected results. USAA (a big insurance company here in the US) is like this. Because they lack context, they couldn't possibly identify a potential issue. 1) Even if they were more aware, they could have said something to their immediate superior (or logged it in their bug tracking software), but the idea/observation was quashed/ignored somewhere along the management food chain. 2) Problems may have been cited, but management decided not to act due to costs. It's not a big leap to assume that management would scrub evidence that indicates this was the case, so saying it doesn't show up in the bug tracking/source controls logs doesn't mean squat. 3) Ultimately, the system engineer should have been included in the acceptance testing phase, and probably be the one to identify the problem - NOT the coders. 4) Even if the coders were "out of their league", how would the coders test something they don't fully understand? 5) What do you want to bet that it was the *engineers* that wrote this code? I woudln't EVER refer to an engineer as a "programmer". They simply aren't. The "hubris" lies with the engineers, not the programmers. If I was a programmer that had worked on that system, and they were trying to claim I was the reason for the flaw, and further, that I knew the actual truth, I'd be pretty vocal about placing the blame where it rightly belongs. Boeing is looking for scapegoats, and programmers are low man on the totem pole. If they thought they could get away with blaming the janitors, they certainly would try. In the end, the guy in charge of Boeing is ultimately responsible.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I agree. There is a vast difference between "coders", "programmers" and "analyst programmers". Coders write code to fulfill the complete specification that are given. Sometimes they given the basic code to enter. Programmers have the ability to flesh out less well defined specification by getting answers to the undefined parts of the specification. Analyst programmers read and question the specification they have been to ensure that the specification meet, and will resolve, the problem for which the specification was written. In addition, consideration has be given to the working environment and management of the project. I have worked in organisations in which management not only dictated the specifications for the features or issues, they also dictated the time estimates to complete the feature or resolve the issue. This environment makes it very difficult to raise questions or even make changes to obvious issues.