Slashdot Mirror


Slashdot Asks: Are You Ashamed of Your Code? (businessinsider.com)

Programmer and teacher Bill Sourour wrote a post last week called "Code I'm Still Ashamed Of," where he recounts a story in which he was hired to write code for a pharmaceutical company. Little did he know at the time, he was being "duped into helping the company skirt drug advertising laws in order to persuade young women to take a particular drug," recaps Business Insider. "He later found out the drug was known to worsen depression and at least one young woman committed suicide while taking it." Sourour was inspired to write the post after viewing a talk by Robert Martin, called "The Future of Programming," who argues that software developers need to figure out how to self-regulate themselves quickly as software becomes increasingly prevalent in many people's lives. Business Insider reports: "Let's decide what it means to be a programmer," Martin says in the video. "Civilization depends on us. Civilization doesn't understand this yet." His point is that in today's world, everything we do like buying things, making a phone call, driving cars, flying in planes, involves software. And dozens of people have already been killed by faulty software in cars, while hundreds of people have been killed from faulty software during air travel. "We are killing people," Martin says. "We did not get into this business to kill people. And this is only getting worse." Martin finished with a fire-and-brimstone call to action in which he warned that one day, some software developer will do something that will cause a disaster that kills tens of thousands of people. But Sourour points out that it's not just about accidentally killing people or deliberately polluting the air. Software has already been used by Wall Street firms to manipulate stock quotes. "This could not happen without some shady code that creates fake orders," Sourour says. We'd like to ask what your thoughts are on Sourour's post and whether or not you've ever had a similar experience. Have you ever felt ashamed of your code?

172 of 280 comments (clear)

  1. cig sorter by HFBondsTrader · · Score: 1

    quadrupled efficiency of the cig sorter (cigarette carton stamping/shipping) module in the largest dry goods shipper in north america before a career change

    1. Re:cig sorter by justthinkit · · Score: 5, Interesting

      I worked (briefly) in a call center where we handled people who had called an 800 number. We asked a series of questions that we read from and filled out on an HTML page.

      I suspected something was fishy and looked at the source -- it was exactly like what Bill Sourour had coded -- it didn't matter how people answered, the same non-result in the end.

      People thought the number would help them, but it was used to harvest information, nothing else. One of the most screwed up environments I've ever worked in.

      --
      I come here for the love
    2. Re:cig sorter by ArmoredDragon · · Score: 1

      I think if every coder gave a damn about ethics, then malware wouldn't be a thing. The author wasted his time writing this piece, in my opinion.

    3. Re:cig sorter by ckatko · · Score: 1

      What about proof-of-concept malware?

    4. Re:cig sorter by The-Ixian · · Score: 1

      I wrote a text messaging campaign interface at one point which was used to snipe magazine subscriptions... not super proud of that.

      However, I did make certain that the DNC (do not call) databases were honored and texts of "STOP" were correctly inserting numbers into the DNC.

      --
      My eyes reflect the stars and a smile lights up my face.
    5. Re:cig sorter by K.+S.+Kyosuke · · Score: 1

      that the DNC databases were honored

      For a moment I thought you were one of them evil Russian hackers!

      --
      Ezekiel 23:20
    6. Re:cig sorter by The-Ixian · · Score: 1

      LOL, yeah, after proof-reading, I figured I should put a definition of DNC for this context.

      --
      My eyes reflect the stars and a smile lights up my face.
    7. Re:cig sorter by DickBreath · · Score: 1

      If there weren't people writing malware, and making it into a big business for profit, then few to zero people would ever bother writing proof of concept malware. Back in about the mid 1980's, before there really was any malware, I remember seeing an example of a hypothetical virus in a textbook. I was browsing it in a bookstore, and I don't remember anything about the textbook other than that it had a black hard cover.

      --

      I'll see your senator, and I'll raise you two judges.
    8. Re:cig sorter by DickBreath · · Score: 1

      I don't have an answer to this question. Is it being unethical if you do what your employer is paying you to do, such as writing malware? I am crystal clear on the employer being unethical. And maybe on the programmer being unethical for accepting such employment. But I'm less harsh on the worker bees than on the higher ups who are probably the ones who both dream up whatever crooked scheme, and who profit the most from it.

      --

      I'll see your senator, and I'll raise you two judges.
    9. Re: cig sorter by jdunn14 · · Score: 1

      That reasoning leads to a "but I was just following orders" excuse and that really shouldn't fly for anything significantly unethical.

  2. Yes by houghi · · Score: 2

    Yes, but I will never admid it in public. I will defend it till the end how others are wrong.

    --
    Don't fight for your country, if your country does not fight for you.
    1. Re:Yes by mlts · · Score: 1

      Similar here. I'm proud of what I have done with my coding, as it solved a problem and fills a need.

      Now, coding style and such... I wind up refactoring everything so it is more readable, files are replaced with constants rather than hard coded, adding some error checking, adding "set -euo pipefile" if in bash, etc. Since scripting is a one-off item, the sooner I can put things like that in a manifest, recipe, or playbook, the better.

  3. Redmond? by gti_guy · · Score: 3, Funny

    We're waiting for a response.

  4. Maybe we should mimic civil engineering by Parker+Lewis · · Score: 2, Informative

    In civil engineering, when any project is bigger then a certain amount, it's required to have a civil engineer signing the project, responsible for all the stuff. Sometimes I wonder if we need a similar regulation in software. By example: if it's covering something sensible to life, like medical, airport, etc, law should require a software engineer signing the project and responsible for it.

    Like on civil engineering, probably this will force software people to really invest in QA (until current days, QA is really, really bad in software).

    1. Re:Maybe we should mimic civil engineering by Anonymous Coward · · Score: 1

      There are plenty of things Civil Engineers should be ashamed of.....

    2. Re:Maybe we should mimic civil engineering by Cassini2 · · Score: 4, Insightful

      Civil engineers design with a safety margin such that their building's don't fall down. I work with a bunch of them. Civil engineers dread the thought that their building falls down.

      What does this mean in terms of software? Software crashes all the time.

      Software systems tend to have really complex side effects. Suppose I design a blood pressure monitoring machine for a hospital. It and a hundred other devices let the hospital run much more efficiently. The hospital only needs 1/2 the number of nurses. Now, someone discovers a bug in security camera, penetrates the network, discovers hundreds of Windows XP Embedded devices, and turns the hospital into a malware farm. (Incidents like this have happened.)

      The hospital is screwed. It can't suddenly double the number of nurses, and even if you did, the nurses are used to the automated equipment. They don't know how to fall back to the non-networked way of doing things instantly. They are out of practice.

      How could an engineer sign off on a system like this?

      On one hand, it is running standard and recommended software (like Windows). Software has went through the FDA approval process. However, on the flip side, the hospital is a sitting duck. These embedded devices are hopelessly insecure, and there is no way to secure them against modern network threats.

      I don't think we have proper methods of describing and solving modern safety issues in embedded systems. We have no proper method of understanding safety with machines built in one country, running software written two different countries, and then running somewhere else. The safety interactions even in a relatively stand-alone machine can be very tough to understand. These network enabled threats make things really hard.

    3. Re:Maybe we should mimic civil engineering by rholtzjr · · Score: 1

      Well, from past experience, the FDA covers most of "medical device" software. But this is just governance on the design, construct, maintenance. Not sure if they are concerned with some of the logic inside the software.

      So does the FDA cover most areas, yes. Does it cover all areas, no. This is the liability the company must assume and creating software that is NOT life threatening is a benefit to both the producer and the consumer.

    4. Re:Maybe we should mimic civil engineering by SoftwarePearls · · Score: 1

      We just need laws that make it a criminal offence to write code, design systems, analyse requirements, write documentation, like nothing matters. Screw readability, screw the bugs (and the risks of bugs), screw maintainability, screw completeness, screw robustness.. just screw it. We "just" need laws that make that attitude a criminal offence. We currently build software the way third world building contractors throw together building materials and call it a building.. only for the building to collapse and kill and cripple people some years later. I've been in IT for 30 years, and am deeply ashamed of how "things are done" .. in the name of the "state of the art".

    5. Re:Maybe we should mimic civil engineering by CastrTroy · · Score: 1

      I think the problem of comparing software to civil engineering is that a civil engineer (or team of them) can design let's say a bridge with full specifications and expect that it's build according to that spec. Such and such grade of steel will be used. There will be support structures here, and here. It will be expected to carry X tons of cars. Then you get skilled workers to assemble the bridge.

      Compare that to software engineering. It's really hard to explain how software should actually be constructed without actually doing all the coding yourself. You can set guidelines for people to follow, but writing code isn't really as close to following instructions as following plans for assembling a bridge. There aren't really any low level jobs when it comes to building software. Each and every person writing code on the software project must be basically a software engineer. At best you could have a software engineer review the code written and send it back if it doesn't comply with the specification. But by the time you read the code and verify that it actually fits the spec and executes properly you probably could have written the code yourself. There isn't really any software equivalent of welding the beams together or driving a steamroller.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    6. Re:Maybe we should mimic civil engineering by Anonymous Coward · · Score: 4, Informative

      What does this mean in terms of software? Software crashes all the time.

      Not in safety critical applications. Writing software for them is a different beast.

      How could an engineer sign off on a system like this?

      With the proper documentation.

      I don't think we have proper methods of describing and solving modern safety issues in embedded systems.

      Google for machine safety standards. IEC 60601-1 seems to be a good starting point for medical devices.
      I've only written code for industrial machinery so I can't say for sure if it contains the necessary information. You typically have to go through quite a lot of standards to figure out the full requirements.

      You have to document not only how the software will handle all plausible input cases but also how the device won't endanger anyone in the case of common hardware failures.
      Some electromechanical devices can be assumed to not fail if you never approach half the marked current.
      Some components are designed to have a defined failure state. You can use capacitors that always break, never short circuits.
      For transistors you have to document how the device will operate in the different possible ways the transistor can break.
      For complex circuits like a CPU you are not allowed to assume that it will remain functional and because of this you need at least two CPUs and have software or hardware that detects if one of them doesn't act as it should.
      Depending on what safety class you are aiming for you might have to use CPUs of different architectures and have different programmers writing the software to minimize the risk of them failing in the same way.

      As you might have figured out you can't just throw in a Raspberry Pi or anything running Windows CE and hope to write life critical applications.
      If you need an OS it will be something like SafeRTOS but most of the time you will skip it.
      You typically have to use window watchdogs to make sure that the code executes within the right time and you need to add checkpoints to make sure that the code executes in the right order.
      You should try to avoid using pointers and dynamic allocation. Yep, that rules out high level languages no matter how safe some people seem to believe they are.
      Exceptions is a big no. You avoid code that doesn't have a determined path trough it.
      If you actually use pointers you will have to document every usage to make sure that it can never be used uninitialized or trash other parts of the memory.
      If you allocate things dynamically you will have to show that allocation failure doesn't lead to safety issues.

      TL;DR;
      We have the methods to write safe software. It's not easy and it is very time consuming.
      If you are interested in doing it I recommend going for an EE degree rather than CS. Reading the standards will be hard otherwise and understanding the possible failure modes even more so.

    7. Re:Maybe we should mimic civil engineering by sinij · · Score: 1

      Software shouldn't crash all the time, it is just that we tolerate that a lot more than collapsed buildings. Software used to be "stuff with computers" but now it is everywhere, so the approach must change.

    8. Re:Maybe we should mimic civil engineering by eegeerg · · Score: 2

      On one hand, it is running standard and recommended software (like Windows). Software has went through the FDA approval process. However, on the flip side, the hospital is a sitting duck. These embedded devices are hopelessly insecure, and there is no way to secure them against modern network threats.

      I work at a hospital. Yes, there are still problems. But things are better in the last 10 years. I disagree that there is no way to secure these devices. Your hypothetical blood pressure monitoring device, if it requires network access, would generally be firewalled at time of install (either by the vendor or the hospital). If the malware operates through the one or two open ports required for communication, a more sophisticated packet filtering rule can be applied.

      Also, you may not be aware, but FDA will generally require a vendor to submit risk analysis. For example, you could use ISO 14971. I think Europe is even more strict. Medical devices still suffer from cowboy coding, but the vendor must mitigate risk, because the risk analysis submitted to FDA might be used to support product recall or lawsuits.

    9. Re:Maybe we should mimic civil engineering by ATMAvatar · · Score: 1

      Compare that to software engineering. It's really hard to explain how software should actually be constructed without actually doing all the coding yourself. You can set guidelines for people to follow, but writing code isn't really as close to following instructions as following plans for assembling a bridge. There aren't really any low level jobs when it comes to building software. Each and every person writing code on the software project must be basically a software engineer. At best you could have a software engineer review the code written and send it back if it doesn't comply with the specification. But by the time you read the code and verify that it actually fits the spec and executes properly you probably could have written the code yourself. There isn't really any software equivalent of welding the beams together or driving a steamroller.

      The mistake you're making is comparing coding to constructing the building. Coding is more like drawing blueprints. The compiler is the construction crew. The early specs/design are more like drawing pictures and building models of the building beforehand.

      --
      "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
    10. Re: Maybe we should mimic civil engineering by Jeremi · · Score: 1

      All well and good until someone bridges the air gap (e.g. By plugging in their infected home laptop)

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    11. Re:Maybe we should mimic civil engineering by Culture · · Score: 3, Interesting

      As a practicing structural engineer for 30 years who also writes structural engineering design software, let me answer this for you. When an engineer signs/stamps a design, they are not certifying that it is perfect. In fact, it is generally recognized that no set of plans is ever error free. What you are asserting by your signature is that 1) You were in charge of and supervised all the work going into the design and 2) The design was performed in accordance with the standard of care for the work being performed. Standard of care is NOT a standard of perfection, by rather "that degree of care and skill ordinarily exercised under similar conditions by reputable members of our profession practicing in the same or similar locality." TL/DR; An engineer cannot sign/stamp shoddy work, but is not expected to perform perfection.

      --
      ----- There are two kinds of people in this world, my friend; those with loaded guns, and those who dig.
    12. Re:Maybe we should mimic civil engineering by NormalVisual · · Score: 1

      It won't until the folks running the show are willing to wait a quarter or two to recognize revenue in order to make sure stuff doesn't break. Which is to say, it won't happen.

      --
      Please stand clear of the doors, por favor mantenganse alejado de las puertas
    13. Re:Maybe we should mimic civil engineering by Kjella · · Score: 1

      Civil engineers design with a safety margin such that their building's don't fall down. I work with a bunch of them. Civil engineers dread the thought that their building falls down. (...) Suppose I design a blood pressure monitoring machine for a hospital. It and a hundred other devices let the hospital run much more efficiently. The hospital only needs 1/2 the number of nurses. Now, someone discovers a bug in security camera, penetrates the network, discovers hundreds of Windows XP Embedded devices, and turns the hospital into a malware farm.

      Except the latter is more akin to evildoers running trucks in complex resonance patterns or planting C4 charges to bring the bridge down. In complex software sure there are accidentally created and accidentally triggered bugs, but those are mostly contained by testing and rollback procedures so what you have today is not worse than what you had yesterday. If it's broken you can fairly easily put a business value to it and prioritize accordingly. And there's not many insider civil engineers who intentionally leaves an exploit or plants a backdoor to bring the bridge down.

      Of course you can still screw up badly like when your Mars probe doesn't convert to metric or your whole system is down or corrupted instead of failing one particular operation on one particular set of inputs. But you're in control of these factors, if you haven't tested the results or that the bits go together it's your fault. If you haven't tested with 10x normal production load that's your fault. If you haven't tested what happens on malformed or out of range input you're not really trying. Specially crafted input with malicious intent is really a quite different ball game.

      To be honest I feel software quality is generally pretty high, most my software runs very stable and rarely give errors - or maybe I'm confusing cause and effect, if it doesn't work well I don't use it. It's not the 90s anymore when it would blue-screen if you looked at it funny. What I worry about is illegal malware like cryptoviruses, password stealers and identity theft as well as an increasing trend of legal "malware" like telemetry, targeted advertising, online activation and other baked-in rights to rape my privacy, void consumer rights and create dependencies on external servers and their terms of service.

      --
      Live today, because you never know what tomorrow brings
    14. Re: Maybe we should mimic civil engineering by K.+S.+Kyosuke · · Score: 1

      Don't make the plugs compatible!

      --
      Ezekiel 23:20
    15. Re:Maybe we should mimic civil engineering by swillden · · Score: 3, Informative

      One difference between the civil and software engineering examples that strikes me is that the civil engineer only has to ensure that the building never falls down due to natural and expected forces. If someone sets off a large truck bomb in the basement, the building *will* fall down, and everyone understands that's not the civil engineer's fault because that attack was outside of the normal and accepted design parameters.

      That's not to say that we don't defend buildings against truck bombs. We do, but we do it with other mechanisms. We have regulations that attempt to restrict the availability of explosives. We have law enforcement and court systems that attempt to deter people from blowing up buildings by threatening them with punishment if they do. In some cases, for buildings that seem to be at particularly high risk, we apply various other security measures to control what vehicles can be driven into the basement, and by whom. We also have infrastructure in place that attempts to monitor whether or not some individuals or groups might be interested in trying to blow up a specific building, and devise and implement countermeasures dynamically as needed.

      In the case of software, the responsibility of software engineers is not nearly as clear as it is for civil engineers. Largely this is because software engineering is still a very young profession as compared to civil engineering, and it's still evolving rapidly. In some cases, the tools and techniques used by attackers didn't even exist when the software was written. In most cases, the tools and techniques did exist and were well-known to attackers and security engineers, but not to the people who wrote the software. This indicates a failure of the profession to educate its members... but given the pace at which attack techniques develop and the pace at which the software industry is and has been expanding, it's a failure without obvious solution. Simply applying the same sort of regulation and procedures applied to civil engineering would be massive overkill that would dramatically decrease the ability of the industry to produce software and probably wouldn't solve the problem.

      Clearly, we need to create more secure software. The status quo is generally terrible. There are exceptions; there are organizations that do excellent security engineering and we have a good collection of tools and practices for making software that is much better than the norm. On the other hand, no matter what we do during development there will always exist the potential for a truck bomb, an attack which was simply outside the parameters that it made sense to defend against. That means we'll always need additional, "active" defenses.

      In the case of the hospital equipment, that means that processes developed for medical equipment not based on software simply don't work. FDA approvals hinder security because they make patching far more expensive and difficult than it should be. We can attempt to build security perimeters around all of the equipment, but experience proves that that's a fool's errand. There's always some way in and once inside the perimeter attackers can run amok.

      Our current (but rapidly evolving!) best understanding of how to make software reliable in the face of active attack is a multi-layered strategy. It starts with good software engineering practices that attempt to minimize well-understood risks (buffer overflows, SQL injection, XSS, etc.). Then we try to add firebreaks wherever possible and reasonable, so that compromise of one component doesn't compromise the system as a whole. Such firebreaks mostly consist in locking down any communication channels between components that aren't actually necessary, within processes, between processes, and between devices on networks. We also try to authenticate users and keep them restricted to the functions they can legitimately perform. Then at every level we do regular penetration testing and work to identify and patch vulnerabilities before they can be exploited -- because there will

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    16. Re:Maybe we should mimic civil engineering by tehcyder · · Score: 1

      Standard of care is NOT a standard of perfection, by rather "that degree of care and skill ordinarily exercised under similar conditions by reputable members of our profession practicing in the same or similar locality."

      This is basically true for all professions, like lawyers or doctors. No person or system is perfect, but an operation by a highly trained and qualified surgeon is many orders of magnitude more likely to succeed than following Baz's DIY appendectomy guide on YouTube.

      --
      To have a right to do a thing is not at all the same as to be right in doing it
    17. Re:Maybe we should mimic civil engineering by ranton · · Score: 3, Informative

      Google for machine safety standards. IEC 60601-1 seems to be a good starting point for medical devices.

      We have the methods to write safe software. It's not easy and it is very time consuming.

      There is still a fairly large difference between quality control in civil engineering and software development, even for safety critical devices. In college I worked with a professor whose area of research was requirements engineering, specifically requirements trace-ability. I did some work on a research project involving Siemens and the FDA where the goal was to improve specifications given to the FDA so they could monitor safety critical devices better. It was very eye opening just how difficult it is for the FDA to perform approval on devices which include a software component.

      Right now their approach is basically to look for what they called "bad smells". It is impossible to thoroughly go over every software system with the same rigor they would over electronics or mechanic systems without an astronomically higher cost. So the best they can do is use their experience on where problems are most likely to be and to focus on areas where documentation is light. Just like an experienced software QA engineer would. My professor's research focused on AI and information retrieval to build tools which assist in investigation because a thorough review would be impossibly costly.

      People often pontificate about whether civil engineering, electronics, or software engineering products are inherently more or less complex than each other. They look at number of bolts in a bridge and the lines of code in a software program and pretend they can compare the two. But coming from the actual mechatronics engineers and FDA officials whose job it is to oversee the safety of these products, software systems have simply too many external and internal inputs for software quality control to reach the rigor of other engineering disciplines. Human beings are simply not capable of handling the level of complexity it would take for software engineers to have the same confidence in their products as a civil engineer has in his.

      Engineer experience and good QA practices really do make a big difference, but no software engineer will ever be capable of taking on the same level of responsibility for his products as a civil engineer does when he signs off on a bridge. This doesn't mean the industry cannot improve (it certainly can), it just means comparing the results of software QA with the results of civil engineering QA will always be faulty. Comparing each other's procedures to find ways to improve is still a good exercise though.

      --
      -- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
    18. Re:Maybe we should mimic civil engineering by mtaht · · Score: 1

      "Ubiquity, like great power, requires of us great responsibility. It changes our duties, and it changes the kind of people we have to be to meet those duties. It is no longer enough for hackers to think like explorers and artists and revolutionaries; now we have to be civil engineers as well, and identify with the people who keep the sewers unclogged and the electrical grid humming and the roads mended. Creativity was never enough by itself, it always had to be backed up with craftsmanship and care â" but now, our standards of craftsmanship and care must rise to new levels because the consequences of failure are so much more grave." - Eric Raymond, in: http://esr.ibiblio.org/?p=4196 see also: icei.org

    19. Re:Maybe we should mimic civil engineering by TheRaven64 · · Score: 1

      QA catches the low hanging fruit. Formal verification catches more (but even then, bugs in your specification can be a problem). seL4 currently has the record for the most efficient formal verification workflow and it cost around 30 times as much as doing best-of-breed QA. Oh, the spec didn't cover everything so it was about 6 hours between open sourcing the code and someone finding a security hole in the system call handler.

      We can do this with civil engineering projects because they're fairly simple (physical systems are limited in the number of interacting parts by 3D physical space - software components are not and any given bit of code may have direct interactions with hundreds of others and second order interactions with vastly more) and because we've been doing them for a long time.

      --
      I am TheRaven on Soylent News
    20. Re: Maybe we should mimic civil engineering by laurencetux · · Score: 1

      and thats why you desolder the contacts when you setup something that needs to be airgapped (or not even put the un-needed jack on)

    21. Re:Maybe we should mimic civil engineering by swillden · · Score: 1

      That is indeed part of the problem. Until people care to pay for secure software, they won't have it.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    22. Re:Maybe we should mimic civil engineering by orgelspieler · · Score: 1

      Small nitpick: you're confusing civil and structural engineers. These are two very different beasts.

      If an engineer stamps something, he is vouching for every aspect of the design. In my state, you actually have to design or oversee the design as it is going on. Granted there are a lot of guys who just stamp the papers to get them off their desk, but that's not technically legal.

      In the software world, you could sign off on the design if you were involved from the ground up. The problem is that in today's world of software, the ground level is so far removed from where you are actually doing your work. I'm not saying you'd need to do machine code, but there are so many layers of abstraction and borrowing from libraries and building on other people's shoddy work that it becomes problematic quickly.

      One saving grace for engineers is that if you are using something that is UL listed or on some otherwise approved list, or certified to a certain standard, you are absolved of any culpability should said component make your system fail (assuming you are using them in the prescribed manner). Say a bolt that you specified was purchased from a vendor who lied about whether it was a certain grade. The bolt breaks and somebody dies. The blame would fall on the manufacturer of the bolt. More importantly, this rarely happens, because the fastener company has a professional engineer who also is concerned about public well-being.

      In the software world, is there a similar certification for third party components? I can't think of one, but I'm just an EE. It seems like the parable of building your house on sand. If your components and operating system are all buggy and crash-prone, no matter how stoutly you build your application, you are still running the risk of the foundation crumbling beneath you, leaving everything in tatters. I think you cannot just throw your hands up and say, "oh well, no matter how good I make my software it will be buggy." You have to dig deep and lay a better foundation. Then build upon it using only trusted and proven components. I guess where this building metaphor really has issues is that there's arguably no bedrock to find. If you want a secure operating system, you're probably going to have to roll your own.

    23. Re:Maybe we should mimic civil engineering by Matheus · · Score: 1

      Your example isn't as far off as you think:

      One of the biggest conspiracy theories around 911 (Please not getting into that argument just an example) is that the building were *designed to withstand an airliner impact and so should not have collapsed. Lawsuits after the fact take such things into consideration:
      If your building is not designed to such standards and a plane flies into it it is expected to fall and liability fall almost entirely with the terrorist. (I know there are exceptions... just in a "sanish" world.) BUT if your building is designed to withstand an airline impact and the building still falls because of faulty design then chances are more likely you'll win a lawsuit against the design firm and maybe the construction firm, etc.

      Here in MN we had another excellent example: The 35W bridge that collapsed. There were *tons of lawsuits after that one and culpability fell on many groups. The bridge was designed to withstand a certain amount of weight but was also many decades old. It was a poor design in-general which is called "fracture critical" where a single failure can lead to total collapse. At the time it fell there were 100s of tons worth of construction trucks all being parked on the bridge along side regular rush hour traffic (think of these trucks much like the terrorist in the first example). You also had state inspectors who had been (or maybe not so much as they should have) regularly checking the bridge to validate its safety. *ALL of these groups were found liable to some extent and had to pay out settlements.

      If you sell software or a service that has a contractual promise of a certain level of security or stability and that software doesn't live up to that spec there are all sorts of lawsuits involved. If you are in a software business where lives are on the line (Health Care, Weapons / Aerospace Tech / etc) then you can be damned sure they'll be coming after you if someone's life is lost. There isn't some magical bubble that keeps us developers from liability for the tools that we produce. The IS however a more acceptable level of lack of perfection given the natore of how complex the systems we create are and, frankly, how much did you pay us to build it right.. what promises did you pay me to live up to.

    24. Re:Maybe we should mimic civil engineering by Matheus · · Score: 2

      PS. To answer the original question: No.
      In the sense of how the question was asked, I have never produced any software that I'm ashamed of what it is used *for.

      BUT there is plenty of code I wrote when I was younger / less experienced that I'm kinda ashamed I wrote... I could write it SO much better today :)

    25. Re:Maybe we should mimic civil engineering by SoftwarePearls · · Score: 1

      Primitive huts? We're drowning in complexity. We've been doing so since the 70s. When is the last time you looked at a project with less than 100K-1M lines of code? We're not building primitive huts, we're building software skyscrapers, nuclear subs and rockets .. that fail all the time.

    26. Re:Maybe we should mimic civil engineering by DickBreath · · Score: 1

      No. Put the incentive where it belongs. Especially in this day of IoT. A company making an IoT product that is vulnerable to be easily exploited and recruited into a botnet should have liability in all of the damage done using their insecure IoT device.

      Now just a clarification. I suggested this some weeks back in a different topic, and got a reply that seemed to think I was suggesting some sort of government regulation, licensing, inspection, registration, or other things. Nope. Just a law that makes companies financially liable for damage done with their insecure things. No inspection or any other such thing. The company should just make a good product. When you buy a home router you don't expect it to burn your house down. Similarly, I don't expect it to participate in bringing half the internet to a crawl.

      Put the financial incentive upon the companies who make the products. Companies making the products may even end up working together to share some of the cost of the work. Maybe a common Linux base used in many different routers, etc. Securing everything by default. No easily guessed default passwords, etc. There might be 0 days. But there can also be patches quickly deployed. And building the infrastructure to update your product is a good idea. Or even better make it so that no such updates become necessary.

      --

      I'll see your senator, and I'll raise you two judges.
    27. Re:Maybe we should mimic civil engineering by CastrTroy · · Score: 1

      What I'm saying is that that is the false comparison people make. Like you said, the software equivalent of the construction crew is the compiler. When building a bridge, only the engineers can make or change the blue prints. If you use this methodology on software, everybody doing any amount of coding should be a software engineer. But if you have a project with 20 developers on it, you now need to hire 20 engineers. This makes things prohibitively expensive.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    28. Re:Maybe we should mimic civil engineering by plopez · · Score: 1

      Or how about creating and selling non-ACID compliant database systems and being proud of the fact.

      --
      putting the 'B' in LGBTQ+
    29. Re: Maybe we should mimic civil engineering by danomac · · Score: 1

      Just get an Apple laptop. It's not compatible with anything anymore.

    30. Re:Maybe we should mimic civil engineering by david_thornley · · Score: 1

      I've worked on software such that a complete failure would be a minor annoyance. I've written Perl for single-use format changes that I just hacked into shape and ran several times until the output was what I wanted, and robustness and maintainability didn't matter. (Yes, I could have done those more efficiently.) I've also worked on code that could kill people if I got something sufficiently wrong. I do those things differently. (No "Oops, killed three people, maybe if I change this parameter....")

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  5. Code of the West by PopeRatzo · · Score: 3, Funny

    Hell, no. I ain't ashamed of my code, and if a man says something bad about my code, there's gonna be some blood spilt.

    --
    You are welcome on my lawn.
    1. Re:Code of the West by The-Ixian · · Score: 3, Funny

      Ah... you are a Klingon developer.

      Your code does not have bugs. It has features which leave a bloody trail of carnage in their wake.

      --
      My eyes reflect the stars and a smile lights up my face.
    2. Re:Code of the West by david_thornley · · Score: 1

      You work at Microsoft?

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  6. I can sort of picture how that VW thing happened by 91degrees · · Score: 1

    I can see this being more about negligence than breaking the rules.

    The emissions requirements are not going to be dealt with directly by all engineers. That will be a management issue. They'll look at all the emission requirements, and basically add that to the requirements.

    The engineer then has two sets of conflicting requirements. Emission below X. Power above Y. There are additional rules though. The emissions requirement is only needed under certain conditions. So the tired, stressed engineer adds an "if()" statement based on those conditions. The manager is uncertain about this but sends it up the chain asking if it's okay. Next person up the chain doesn't understand or want to understand the technical details. All he cares about is that the emissions test is passed and the performance isn't affected.

  7. Re:No, but I'm... by Big+Hairy+Ian · · Score: 1

    I write spaghetti code just like everybody else! Why would I be ashamed of that. I am ashamed of some of the industries I've worked in as a programmer (Abattoir, Time Share, Direct Marketing but most of Estate Agency (That's realtor for those of you on the wrong side of the pond))

    --

    Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

  8. We're all prostitutes by codeButcher · · Score: 5, Insightful

    I thought "ashamed of code" would be e.g. using a for loop on a Java Collection rather than an Iterator; or using EJB methods to simply wrap database layer calls, instead of encapsulating business rules (because you see our project uses a 3-tier architecture because someone somewhere read it is a good thing to do); or not doing unit tests.

    Writing code to put bread on the table for employers whose business ethics are questionable (or cut corners when it comes to generally accepted good software engineering practices) is to be expected. It's not as if these things are discussed at the hiring interview. And jumping ship at the drop of a hat when these things crop up is seldom practicable - a new round of interviews takes time, so does induction into a new workplace.

    We are all prostitutes, either from the neck up or the neck down.

    --
    Free, as in your money being freed from the confines of your account.
  9. Nested IFs by entropy01 · · Score: 1

    I am not a coder although I know enough to throw something together. At my previous job I was working on a simple interface for looking up part numbers and viewing the corresponding CAD drawing. I had the logic figured out based on what they told me they wanted. Meanwhile, I got another job and I put in my two weeks notice. As I had them demo the new software, we discovered a few edge cases that weren't accounted for. Not having time to figure out the "best way" to accomplish this programmatically, I threw in a few nested IFs. Another day of testing, more edge cases, more IFs. By the end of the week I had 20-some nested IF statements and the code was slowing down. I was out of time, so that's how I had to leave it. The last time that I compiled the code I left a remark for the next poor IT soul who found that pile of slop. I apologized and said that if it ended up on TheDailWTF I would understand. Not life and death dependent software, but I didn't like leaving my name on something I wasn't proud of.

  10. Remember Mordin Solus by DdJ · · Score: 4, Interesting

    I've at times had to code up things I haven't been happy with, but rather than refuse to do it, I tried to modularize stuff so it could be fixed later when management changed.

    This is, I think, better than refusing, and having someone else code it up. To quote Mordin Solus, "someone else might have gotten it wrong".

    (And in at least one occasion, that worked -- for one product I worked on, we managed to safely and quickly kill the "phone home" DRM before it got out into the wild. Felt filthy working on it, felt good to bury it.)

  11. Re:I'm always proud of my code by gatkinso · · Score: 1

    The efficiency of code that is never deployed is zero.

    --
    I am very small, utmostly microscopic.
  12. Mistakes vs Malice by gatkinso · · Score: 1

    The airline example, tragic as it is, is an example of a mistake. Preventable perhaps, but still a mistake.

    The VW example is malice.

    Cannot compare the two.

    --
    I am very small, utmostly microscopic.
  13. No but by Big+Hairy+Ian · · Score: 3, Interesting

    I am ashamed of some of the code that's been written in programming languages I've written

    --

    Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

  14. Re:I'm always proud of my code by kkretsch · · Score: 1

    undeployed code is bug free - sort of. At least it never crashed.

  15. Lets not change anything about being a programmer by Deliveranc3 · · Score: 1

    Until we're out of the limelight, the idiocracy will just fuck it up.

  16. Not so much by MrBoring · · Score: 3, Insightful

    The last thing programmers need is a power grubbing QA task manager on top of the idiot scrum manager, in addition to whoever else wants to run things. Quality starts with planning and thinking before coding and not rushing code out the door. A better approach would be not allowing non software people the ability to make statements of quality, cost and capability about software, via legal fiat. Let software engineers as individuals sign off on it.

    Folks there's a lot less science, predictability and consensus in the legal profession. People need a license to cut hair. If software as a profession isn't to be regulated, neither of those professions should be as well.

    1. Re:Not so much by Nidi62 · · Score: 1

      Governments shouldn't be regulating or licensing any professions afaic, we need less government in our lives not more. Of course the west decided otherwise so the jobs left and will keep leaving.

      Yes, so many jobs like doctors, pilots, and even Uber drivers are leaving this country in droves all due to over-restrictive government licensing. Or, you know, maybe licensing for professions that carry significant risk to the lives and properties of others and in many cases involves significant amounts of training and education is one of the few things government actually should do.

      --
      The only thing necessary for evil to triumph is for it to be pitted against a slightly greater evil
    2. Re:Not so much by mlw4428 · · Score: 1

      I sure want the guy working on my heart to be totally clear of licensing. I mean, heck to proving that you're a capable heart surgeon. I can just sue from the grave or give a bad Yelp review!

    3. Re:Not so much by udachny · · Score: 1

      training and education is one of the few things government actually should do.

      - no, it shouldn't. It shouldn't do any of these things and the fact that they are doing all of that is exactly the reason that jobs are leaving and they will leave, I include doctors and pilots and Uber drivers as well. Yes, all of those will disappear too, some due to outsourcing (doctors), some due to automation (drivers and doctors), some due inability of the public to pay without being productive themselves (pilots and doctors and many others).

    4. Re:Not so much by udachny · · Score: 1

      How exactly do you think you rate doctors today, by their diplomas or their experience? Because AFAIC I only care about experience and their reputation, not any of the licensing nonsense.

      Sure, sure, there can be rating agencies and there are rating agencies and they should have nothing to do with any government, because that's where the corruption comes from (like in the banking industry, where rating agencies are not allowed to rate government bonds anything below A or they lose their license to rate government bonds as was the case with Egan-Jones agency).

      I don't care about licensing, I only care about experience and reviews, yes.

    5. Re:Not so much by mlw4428 · · Score: 1

      That licensing nonsense is gained by a physician demonstrating to a board of his/her peers that they are capable and competent in their practice. It also ensures that, throughout their career, they maintain at least a minimum level of ethical and moral behaviors - along with legal obligations. Not every "crime" or "offensive" action a physician does is strictly illegal. A doctor over prescribing pain meds is an example of where a license board can demand a doctor explain themselves. Complicated, ever changing, entirely situationally based laws are not needed, because a licensing board can call a doctor up and say "Why did you do this." That doctor then has to justify his/her actions or face repercussions (such as the temporary or permanent revocation of their medical license).

      It's foolish to only care about reviews - it shows a total lack of ignorance to the medical profession and the challenges it faces in ensuring that doctors are treating patients appropriately.

    6. Re:Not so much by udachny · · Score: 1

      I disagree, for me reviews and experience is good enough. However in the *free market of ideas* you could have your licensing done by a rating agency (not government) and you could go to a more expensive doctor who would be rated/licensed by a *private entity*. I don't see why you want a government doing this given that government does not let any form of competition to exist, wouldn't you rather have competing agencies as opposed to monopolistic ones setting your prices as well as providing reviews/licensing (if you are interested in paying for such a service?)

    7. Re:Not so much by udachny · · Score: 1

      Well, I've been running a medical experiment on myself for the last 22 years...

    8. Re:Not so much by roman_mir · · Score: 1

      That tells us nothing. If you want to put it that way, everybody is running a medical experiment on themselves

      -no, an actual medical experiment, but that is really none of your business, is it?

  17. Re:No, proud of - most times by Anonymous Coward · · Score: 1

    The problem with your site is that there are segments for Java and Javascript... No one can love these inferior languages.

    On a more serious note. The theme is too dark. I also don't believe a message board is a good use for what you want to do. Forums are great for communities, not great for submitting and browsing code quotes... I think something like bash.org would be more successful for what I imagine you're trying to do... From there you can link to your forums....

  18. Re: I'm always proud of my code by Anonymous Coward · · Score: 1

    You sound like a guy I fired two years ago.

    He thought that he wrote flawlessly elegant code. Gave me a book about patterns and said I could use it.

    He was working on a project for three years that never deployed. The guy we hired to replace him wrote it from the ground up in a month. It wasn't elegant, but neither is eating horse meat and cardboard casserole because you lost your job.

  19. Re:No, proud of - most times by kkretsch · · Score: 1

    On a more serious note. The theme is too dark. I also don't believe a message board is a good use for what you want to do. Forums are great for communities, not great for submitting and browsing code quotes... I think something like bash.org would be more successful for what I imagine you're trying to do... From there you can link to your forums....

    I feed some of my code examples for further use to https://snippet.wiki/wiki/Main... which is another site of mine. The forum I installed mainly for sentimental reasons as forums are dying all over the world with users migrating to FB.

  20. Thought this was about poorly written code. by Deliveranc3 · · Score: 1

    Which would also make an interesting story.

  21. Realization... by west · · Score: 5, Interesting

    If we're talking about how are code was used, I remember in high school (many moons ago) writing Turbo Pascal programs and Lotus 123 macros for a shipping department of a sizable company that hadn't yet computerized. I was brought in by the manager of the shipping department because he could hire a high-schooler when he couldn't get authorization to computerize from within the internal IT department (which was busy sinking the company with some massively expensive software controlling the manufacturing).

    Anyway, I was very proud of allowing my boss to get all the data that he wanted, and he was very, very pleased that his department now had some means of seeing what was going on.

    I distinctly remember when he called me in and thanked me. Due to my program, he'd had enough data to improve efficiency 25%!

    I glowed.

    Now he'd been able to let go 2 out of the 8 drivers they had.

    I stood there speechless.

    There were real people underneath those numbers.

    1. Re:Realization... by 110010001000 · · Score: 3, Insightful

      That doesn't matter. Maybe getting rid of 2 of the 8 kept the company afloat so the other 6 didn't get laid off.

    2. Re:Realization... by LordWabbit2 · · Score: 2

      Yeah, been there done that. Rewrote a system that needed a lot of manual intervention (checks and such) because it was so... crap. The look on some of the peoples faces when we were giving a demo, when they realized that their jobs had been fully automated, was really painful. But that's unfortunately a big part of what we do, we automate stuffs, and at the rate of AI growth it's not going to be long before we automate ourselves out of a job, which is like a big ass karma thing I'm sure.

      --
      There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
    3. Re:Realization... by Tablizer · · Score: 1

      and Lotus 123 macros for a shipping...Now he'd been able to let go 2 out of the 8 drivers they had.

      That's okay, they'll be hired back as coders to figure out your spaghetti code after you leave ;-)

    4. Re:Realization... by strikethree · · Score: 1

      I distinctly remember when he called me in and thanked me. Due to my program, he'd had enough data to improve efficiency 25%!

      I glowed.

      Now he'd been able to let go 2 out of the 8 drivers they had.

      I stood there speechless.

      There were real people underneath those numbers.

      Thank you for sharing. Your story really hit me, as it did you. I can clearly imagine and understand the hot/cold that you went through with that.

      Honestly, I would have hoped that they would/could find another position for those 2 drivers instead of dumping them out on the street. *sigh*

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    5. Re:Realization... by david_thornley · · Score: 1

      Economic progress depends on eliminating jobs. If we can't free up people to do new jobs, we can't fill those new jobs. It can cause a lot of hardship in the short run, but it improves standards of living in the long run.

      What would life in the US be if we needed 80% of the population doing basic farming?

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    6. Re:Realization... by west · · Score: 1

      The point of my story was not that automating jobs is bad (or good). My point is that it's easy to forget that there are real world implications to what we do, especially for the young or inexperienced.

      My shame is not in automating those jobs away. My shame (although I excuse it by being a 17 year old adult approval junky at the time) was that I didn't even consider that my job *could* have real world implications.

    7. Re:Realization... by west · · Score: 1

      > Honestly, I would have hoped that they would/could find another position for those 2 drivers instead of dumping them out on the street. *sigh*

      They may have actually done so or, given the trucking industry was booming at the time, they may have found jobs the next day. The boss obviously wasn't losing any sleep over it. (He used to regale me with stories of the games the employee truckers and shippers would play before he instituted some minimal controls on how and what they were shipping. Mostly low-level stuff - hire the trucking firm whose president invited the factory shipper out to his cottage for a few days each summer, or pretend to pick up a non-existent shipment from a customer that was close to a trucker's girlfriend's house, that short of thing.)

      But yes, hot and cold is exactly the right description. I was a bit of an approval junky, and my work was being taken seriously by *adults*! And then suddenly, I had cost *real* adults their jobs.

      As I said elsewhere, the shame is not improving efficiency, it was that I didn't even consider the *possibility* humans could be affected at all. I guess it was a lesson to learn early...

    8. Re:Realization... by west · · Score: 1

      Dear God, you are so right.

      Lotus 123 macros were my introduction to the fact that "tools that you don't have to be a programmer to use" actually means "tools that end up being *immensely* more complex than any computer program because we don't actually give you the constructs to program sanely".

      To this day, I still find people who loudly claim they are non-programmers because programming is too tough who maintain 'macros' whose complexity put my 100,000 line programs to shame. If they'd been given real tools, they'd probably have created human level AI during their coffee breaks, except, of course, "real tools are for programmers" and that would be 'too difficult' for them to even contemplate using.

      I'd feel more shame for what my spreadsheet did to the sanity of the poor soul who came after me, but there was simply no way to sanely code 123.

  22. It's a touching story by jenningsthecat · · Score: 2

    It points out a real problem, and I'm glad the author has the conscience to care and to promote change. But I wonder what can effectively be done. In the average corporate environment, senior programmers are typically read in on the business details only on a need-to-know basis. Low-level code slingers usually don't get told jack. It's pretty difficult to act according to one's conscience given such a dearth of information. And if you demand more information - well, there's always someone waiting to take your job who'll just shut up and code.

    The video linked in TFS points out that civilization depends on programmers. For a century or more, it has also depended on engineers; yet we still have Volkswagen-like scandals, not to mention all the mostly-unnoticed little day-to-day ethical compromises made by engineering staff in the name of business. It seems to me that the only solution is for designers and implementers to have a say equal to that of bean-counters, PHB's, and investors. And in our current world-wide corporotocracy, that simply isn't going to happen - at least not in the absence of bloody revolution.

    --
    'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
    1. Re:It's a touching story by SirSlud · · Score: 1

      Uh, of course you "still have" bad things that engineers do, but it'd be a lot lot worse without professional engineering bodies that regulate certification, and the social science courses that most (all?) BEng programs mandate. Don't kid yourself.

      --
      "Old man yells at systemd"
    2. Re:It's a touching story by thoughtlover · · Score: 1

      Yeah, it's nice to inflate the 'need' of some profession that makes doing things easier... but that's what we're supposed to do when faced with tasks that are tedious and repetitive!

      I think we all depend on farmers more than coders when it comes down to it.

      You can't eat your code.

      --
      No sig for you! Come back one year!
  23. IMO this is a problem of experience. by generic_screenname · · Score: 5, Interesting

    I've seen some shady things, and it was ALWAYS in a setting full of people too junior to ask questions. Junior people are sometimes naive, and will believe management when told that certain shady things are normal. Junior people may have no resume to speak of and are basically forced to look good at their first real job. Junior people may not be able to afford to quit without having something else lined up, and don't want to be marked as job-hoppers. Senior people have the marketability to leave, and the experience to see through BS. They may also have enough savings to quit out of principle and take a sabbatical, or the ability to shift gears to their side business. I don't really know how to solve the problem, given that young adults need to eat regardless of their ethics. I do know that the problem is hardly contained to computing. Maybe we gravitate to this field because we love logic, but the rest of the world isn't logical. We still have to deal with human nature in this field too.

    1. Re:IMO this is a problem of experience. by RyoShin · · Score: 1

      I don't really know how to solve the problem, given that young adults need to eat regardless of their ethics.

      This is another problem that UBI/"mincome" can alleviate. With that guaranteed safety net, people in general won't put up with bullshit like and walk, or refuse and be fired.

      Companies will shape up real quick when their employees are comfortable quitting if management tries to screw them over.

  24. Civil engineers suck by HBI · · Score: 1

    Some of the highway projects on I-95 interchanges in Maryland should be examined for poor design - imagine spending millions on infrastructure to make the traffic worse and accidents more likely?

    --
    HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
    1. Re:Civil engineers suck by MiniMike · · Score: 2

      imagine spending millions on infrastructure to make the traffic worse and accidents more likely?

      I suspect that was the design intent. There must be sadists working in the Highway Administration. These designs (including I-270, I-495, and local roads) could not have been achieved by mere incompetence.

    2. Re:Civil engineers suck by mrchaotica · · Score: 3, Insightful

      I am both a civil engineer and software "engineer." I have also visited Maryland. I can confirm that (a) civil engineers suck (despite the fact that civil engineering is often much less complex than software engineering), (b) Maryland's freeway design is weird (lots of super-tight parclos with really short merges), and (c) calling programmers "engineers" is a complete farce because compared to actual engineering, all coding is "cowboy coding." I don't care if you're "agile" or "waterfall" or how good your code review or QA is; the process is not rigorous enough to count as engineering.

      Ironically, some of the worst cowboy coders I've worked with have been Professional Engineers...

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    3. Re:Civil engineers suck by HBI · · Score: 2

      Well, I learned what a 'parclo' was, so thank you.

      Writing software is like building atop unstable ground and never finding bedrock. Even well written code is unable to entirely isolate itself from the stability issues of its platform with any level of assurance. Software cannot be relied upon absolutely. So while I agree with you that calling coders engineers is wrong, it's probably for a different reason than bad code.

      --
      HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
    4. Re:Civil engineers suck by BronsCon · · Score: 1

      Ironically, some of the worst cowboy coders I've worked with have been Professional Engineers...

      I'm not sure that's irony; the most likely explanation seems quite logical to me. When they put on their (credentialed) engineer hat, they must follow strict procedures or face heavy consequences; when they take it off, they can finally relax, so they do.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
    5. Re:Civil engineers suck by ikedasquid · · Score: 1

      Most "software engineers" are not engineers. I also agree that programmers are also not engineers.

      Many people (even those with the title "software engineer") believe that there are no software engineers....but they are wrong.
      I work in the avionics industry, and regularly engineer software that runs on the aircraft's primary flight display. I can't compare the rigor of SW engineering to civil engineering, but I can compare it to electrical engineering (I work closely with teams of systems and electrical engineers). From an aviation certification perspective, software engineering is at least as rigorous as electrical engineering.

      Actual software engineering (at least from my experience) is about 10% "writing source code". That 10% includes reviewing source code that others have written. I would guess that about 40% of effort is spent in iterations of requirements capture and generating designs, and the final 50% is testing. Designs includes things like "requirement says X action must occur no later than 4 ms after Y event is detected, and since the scheduler runs at 100 Hz we cannot use a thread to invoke the action - so the action must be called from the thread/task that detects the event". Unlike typical "cowboy programming", there is a lot of focus on minimum performance in worst case conditions, error handling, hardware fault detection etc. Testing includes the standard "requirement says transmit X packet when Y condition is met, so induce Y and check for X" to "manually verify that compiler generated the expected object code given the source code". Additionally, for the highest safety levels (think large commercial passenger aircraft) every line of code will be executed during test, every possible branch will be taken during test, and all "truth tables" will be fully exercised during test. Google DO-178C MCDC

      The final software produced is of exceptional quality (obviously) and is written in C or Ada (no OO, no interpreted languages). If the system will use an OS (many don't - some are runtime executables instead of applications) it won't be Windows Embedded or Linux. It would be a certified OS (Integrity-178, LynxOS-178, or VxWorks Cert).

      One final observation - there are basically no hipsters where I work. It's pretty much all 30-50 year old men, dress shirts and slacks.

    6. Re:Civil engineers suck by johannesg · · Score: 1

      Do you have any ideas how could the process be made more rigorous? Preferably in a way so as not to multiply the cost of the process by a factor 1000 or more?

    7. Re:Civil engineers suck by myrdos2 · · Score: 1

      calling programmers "engineers" is a complete farce because compared to actual engineering, all coding is "cowboy coding."

      Be fair. We never said they were good engineers. I've always felt that calling it "Computer Science" was a stretch... even the theoretical parts of software development are really applied mathematics. What software architects are actually doing looks a lot like engineering... they're building (virtual) components, and fitting them together to build a virtual machine to accomplish some goal. It's just that we don't know how to reliably measure the quality of any given piece of code. So it could have the sophistication and grace of two Volkswagens duct taped together at a 90 degreee angle, but it still somehow works most of the time if you're lucky.

      Anyways, my point: shitty engineering is still engineering.

    8. Re:Civil engineers suck by bongey · · Score: 1

      Curse be the man that uses orange barrels and construction ahead signs to torture the population.

    9. Re:Civil engineers suck by plopez · · Score: 1

      Like Governor Christie?

      --
      putting the 'B' in LGBTQ+
  25. Blame Managment by shawnhcorey · · Score: 1

    Any bad code I write was because of bad management: lack of specifications, deadlines, lack of QA, etc. ;)

    --
    Don't stop where the ink does.
    1. Re:Blame Managment by david_thornley · · Score: 1

      Yeah, but sometimes I've been my own manager, written my own specs, set my own deadlines, did my own QA....

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    2. Re:Blame Managment by marekjm · · Score: 1

      Ah, yes. I guess we've all been there. When I set deadlines on my own projects they are reasonable (it's "ship when it's tested, and debugged" rather than "ship next week, no matter what"). When I write requirements for my own projects I try to keep them sane. I also get to choose tools best suited to the task. At work I have no such power. And even if I voice concerns, the project manager can just not listen.

      --
      Check out my virtual machine: http://viuavm.org/
  26. Doesn't this describe almost every job? by darkitecture · · Score: 4, Insightful

    Doesn't this describe almost every job?

    I mean, I generally agree with the article. But the article seems a little... self-aggrandising, doesn't it? As if to say "hey, we're just as important as doctors and engineers!"
    The thing is... I kinda agree - programmers are very important and their actions can have serious consequences if done poorly or incorrectly. But like... plenty of other jobs are just like that too.

    If the person stocking the shelves at your local grocery store doesn't clear out the expired stock, or maintain proper hygiene around fresh food, they could easily contribute to someone getting sick or spreading bacteria or a virus.

    If the person selling gear at a bicycle store doesn't realize the wheel or frame is broken, or that a frame has been recalled due to a defect, they could easily contribute to someone being seriously injured.

    If a school teacher ignores serious bullying or doesn't fact check the information they're teaching or doesn't make sure their students properly know how to do proper calculations, they could easily contribute to a serious mistake made by the student some time in the future.

    If a salesperson helps someone get a loan approved when they've very much shown in all likelihood that they probably can't afford the monthly payments or that the loan is predatory in nature, they could easily contribute to that person's life taking a serious financial turn for the worse - and we all know how stressful and desperate people can get when they can't make ends meet.

    Yes, programmers need to be aware of their moral compass - but so does everybody else to varying levels, pretty much. Generally speaking, just - don't be a dick, don't be apathetic and use some common sense. That'd go a long way for pretty much anybody in any situation.

    1. Re:Doesn't this describe almost every job? by SoftwarePearls · · Score: 2

      The big difference between the everyday examples you quote, and contributing to software systems, is what I call the invisibility of the software. No bystanders can instantly judge you to be criminally incompetent when you write code that is so buggy, so fragile and so unsuited to control any aspect of society. Whereas any bystanders witnessing your example actors (shelf stocker, bicycle shop seller, etc..) can instantly judge your example actions as being immoral. That is why we constantly get away with murder: our core artifact is totally incomprehensible to virtually everyone around us. This incomprehensibility even starts within our software teams: we write stuff that even our team members can't understand, let alone our managers, our project leaders, our bosses, our clients. I'm afraid your comparison therefore ignores this fundamental difference. Software realities mean 99.99% of developers act as lone cowboys.. without any pressure to act in any way in a professional manner (professional as defined by the dictionary, not as defined by our industry).

    2. Re:Doesn't this describe almost every job? by mrchaotica · · Score: 1

      Agree completely. The fundamental problem is that software tends to have so much more combinatorial compexity than just about everything else (except maybe medicine or law), and even strategies used to reduce the complexity (modularization and encapsulation) that work in fields like engineering are, in software, often broken or ineffective due to poor design. (Imagine if the person designing the plumbing system in a skyscraper couldn't rely on the walls and floors staying in the same place. He'd have to invent servo-actuated movable plumbing or something, and it would be many orders of magnitude more complicated and less reliable than actual plumbing. It would be chaos! But that's how we do it in software...)

      --

      "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    3. Re:Doesn't this describe almost every job? by avandesande · · Score: 1

      That's silly. Should the assembly line workers that made the pinto be ashamed? Nobody sees them.

      --
      love is just extroverted narcissism
    4. Re:Doesn't this describe almost every job? by thoughtlover · · Score: 1

      That's silly. Should the assembly line workers that made the pinto be ashamed? Nobody sees them.

      No, but the designers and engineers should be!

      --
      No sig for you! Come back one year!
  27. No shame by symes · · Score: 2

    I avoid shame by making sure my code does not work and is not seen by anyone else.

  28. Robert Martin's talk by SoftwarePearls · · Score: 2

    I also saw Robert Martin's talk, and generally agreed with it. I am generally surprised (and disappointed) at how insensitive and irresponsible colleagues are. At the end of the day, most just want their salaries in their bank accounts, and keep their jobs. Software engineers appear to be just like everyone else. So I agree with Martin that laws are badly needed.. to root out the cowboy/hacker attitude for this coming century. On the subject of Martin's talk, I actually bought his book "Clean Code" as a result of seeing his talk. Robert should be ashamed of his book though.. if it's to be an example of the self-regulating quality consciousness he's talking about, the book is the opposite (it lacks writing discipline, among many other qualities).

  29. Re:No, but I'm... by Anonymous Coward · · Score: 1

    And you should be ashamed of your spelling and random capitalization of words.

  30. Its a matter of flowcontrol. by Mysund · · Score: 1

    Not been ashamed after i startet replacing all flow control structures with goto's

  31. This is not so new by rickb928 · · Score: 1

    And even back in 1985, software was killing people, gruesomely. Probably before.

    And it was testing that failed back then. Nothing much changes. Agile process has given project managers a way to avoid testing as a function, and so there is no real testing. Hilarity ensues.

    --
    deleting the extra space after periods so i can stay relevant, yeah.
    1. Re:This is not so new by Ihlosi · · Score: 1
      And it was testing that failed back then.

      In that particular case, it wasn't just testing.

      The bug could have been caught by someone reviewing the code, if the manufacturer had spent the money.

      The bug could have been caught during testing ... maybe (there was some randomness involved).

      The bug could have been caught after the first reports from users about erratic behavior of the device came in.

  32. I'm ashamed of my code by IWantMoreSpamPlease · · Score: 1

    I code in COBOL.

    I'm so sorry. Please forgive me.

    --
    So rise up, all ye lost ones, as one, we'll claw the clouds.
    1. Re:I'm ashamed of my code by 91degrees · · Score: 1

      I think that makes you a victim rather than a perpetrator.

    2. Re:I'm ashamed of my code by IWantMoreSpamPlease · · Score: 1

      Thank you. After COBOL I did Assembly.... ...the horror, the horror.

      --
      So rise up, all ye lost ones, as one, we'll claw the clouds.
    3. Re:I'm ashamed of my code by david_thornley · · Score: 1

      I told my son that, if I found porn, drugs, and a COBOL book under his bed, I was going to go up to him and say, "COBOL? Really? Where have I failed?"

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  33. That escalated quickly by in10se · · Score: 2

    That escalated quickly. I assumed they were talking about how ashamed I am about that spaghetti code I wrote for my client last week, not killing people.

    --
    Popisms.com - Connecting pop culture
  34. Ethics and intent by petes_PoV · · Score: 2
    This piece isn't about the code per. se. It is about the use it is put to.

    Some people might set out to write software that is ONLY usable for malevolent purposes - and they could be fully aware of this when they do the job and deliver the result. Just like some people will work in cigarette factories. Or design more "efficient" land mines.

    However, the vast majority of software that is used for evil can also be used for good. Take GPS for example. It can be used to guide ambulances to accident victims and it can be used to guide missiles to their targets (it can also be used to make those missiles more accurate thereby reducing collateral damage - go figure).

    Is the person who invented the for() loop responsible for all the unknown uses it is put to? Is the team that fixes a bug in car's firmware responsible for saving lives? These are unknowable points. The best that programmers (and testers and designers) can do is to produce high quality work, that fits within their ethical framework. Then sleep easy at night.

    --
    politicians are like babies' nappies: they should both be changed regularly and for the same reasons
  35. This is fake news by Grand+Facade · · Score: 1

    being ashamed of your code is completely different thing,
    than being misled to write code for something unethical.

    But the other side of the coin is there had to be enough clues to make you aware there was something fishy.

    Are/were you desperate? Or are your blinders that big?

    So Yes you should be ashamed.....

    --
    Rick B.
  36. A Deepness in the Sky briefly touches on ... by skidv · · Score: 1

    I recently started reading A Deepness in the Sky (https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky ) by Vernon Vinge who briefly touches on this issue.

    He speculates that eventually hardware will stabilize allowing code written over the period of centuries to still be used. He says that bugs in old code, (the original designer, coder, maintainer are dead) eventually cause more deaths than hazardous activities like space travel.

    I can see how code that hasn't needed TLC for years but is still used extensively (i.e.in chains like awk and grep) could have an impact on computing for years to come.

    Vinge also talks about how back doors created by the coders but forgotten over time might be rediscovered and lead to control and manipulation of massive systems that still use those old libraries.

  37. Nope. by ledow · · Score: 1

    Not ashamed of anything I do professionally, as if I'm made to do something I don't like, I air my objections and go full "I told you so" if it fails, and make sure the responsibility lies in the direction of the people who overruled me.

    Anything more shameful, I wouldn't be doing it. The people who code malicious junk just because their company wants it? Those people might well have something to be ashamed of. Even if they "moved on soon after" or whatever. You should have just not done it if you were that close to leaving anyway.

    There's a line - for instance if you work at a firm that makes DRM for a living, and you have some not-unreasonable DRM, I see that as okay. There are uses and nobody is being forced to use your product over any other.

    If you work at a software firm that sucks in that DRM product, I see that as more dubious. And if you work at either at are installing overreaching DRM into your software, then I see that as very dubious.

    But once you get into life-critical systems, you're not just a coder, and anyone who employs, utilises or fails to hold such coders to the relevant standards (by specifying, testing, etc.) is inexcusable. The VW is an example - you have pumped pollution into the air deliberately bypassing air quality standards, in order to sell a few more units. You knew you were doing it, it was quite obvious what you were doing, why you were doing it (your engines are shit and can't compete with others that didn't need to cheat), and that you'd GONE OUT OF YOUR WAY to do it. No excuse. And the coders there must have known what they were being asked to do (nobody "accidentally" codes a routine to detect the official testing procedure) and should take responsibility for that.

    And if you get sacked for failing to code something that's illegal or hugely damaging, well then you REALLY don't want to be working for that company in the first place. First, you can then sue them into oblivion and cause them a lot more problems than they can cause you, and secondly they're scumbags who will drop you in it later if you don't do it to them first.

    Apathy, ignorance and laziness are the biggest problems, though. "Do we need to test this? Nah." has probably led to more deaths in more industries than anything else.

    But personally? My conscience is clear, not just because I can gloss over things I've done. I've either objected, vocally, and then held people responsible when it's gone wrong, or I've refused or got out of there.

    I had stood, in front of the top-boss, and point-blank refused to perform an action they were demanding. It was illegal. It was unnecessary. And I refused to do it. To their face. Despite their threats. It's just not going to happen. I'm sure someone else would do it for them, but that's tricky after I reported them for doing exactly that, quite publicly, and documented my response to them.

    Now try and deny you weren't trying to get me to do something I shouldn't, or that the next guy "didn't know" that he shouldn't. Because for damn sure I made sure he would, and stopped you continuing down that line of thought to make him responsible for it too. I wouldn't have minded so much if it hadn't been the most petty and worthless course of action ever anyway, at least then you could see who would have profited from my doing it.

    But there is no way I'm going to break the law for you, break the rules for you, or - if you act like that - do you any favours that might help your cause.

    I am surprisingly alone in such things, I've watched any number of people keep their head down, stay quiet, and just do things they should never have been doing. They wouldn't ever back you up (except in the over-a-cup-of-tea kind of way), take a stance, or fight your corner. I know that much. But I'm always shocked at quite how many people that applies to.

    Me? Just try it. There's a line, a bit of flexibility and freedom where you can say "Look, does it matter, are we hurting anyone at all, is it important, etc."

  38. Re: I'm always proud of my code by orlanz · · Score: 2

    I always wonder what the hell those people do when I'm gone.

    They will be fine. They were just looking for the easiest and most simple path to get an answer. It was you. Without you they will use a little less simple path. They may even Google the answer! Hell, they might even learn something.

    In general, people who seek help are neither as helpless nor stupid as they appear to be.

  39. Re:I'm not ashamed of it... by Pascoea · · Score: 1

    I was tasked with getting 10,000 lines a day out

    I smell BS. Impossible task during an 8 hour day. (1 line of code every 3 seconds, assuming you never took a break.)

  40. Not really, no. Here's why ... by Qbertino · · Score: 2

    The very nature and absolutely empowering thing about software is that it is flexible. It's purpose abstracted from the machine that fulfills the purpose. It doesn't get any more awesome than that. That's why we are gods in our own little world of the systems we work on and that's why we love tinkering with and building software.
    That's the whole point of it.

    So when I dig up my old EDI connector/serial processing ERP software I wrote 14 years ago in Python I don't think "OMG! What was I thinking? This abstaction is non-existant and if it is it's abysmal!". I think about the other things: How I wrote the filters for Amazon Marketplace before they even had an open API. How chains of regexes filtered the competitors pricing and how another script adjusted ours one cent cheaper than the cheapest offering of our competitors. How orders went from 15 to 120 the day we started using those scripts. How we were adjusting to changes in amazons websites on a daily basis, and how we built a billing system with Python, RTF Templates and an cli-automated Open Office.

    If you look at that code today without context you'd think it's some bizar experiment or something. But it pushed our revenue back then from 20 000 Euros to 480 000 Euros.

    Same goes for the very first Flash video and multimedia streaming client that I built. The code looks a mess and the player works very strangely. But we had to find out the hard way that you have to render your objects off screen in order to force the flashplayer from back then to actually load them. Likewise, if you call an XML object in Flash 4 / ActionScript 2 without instancing it, the Internet Explorer would reference the file on the far server, reloading it every time and causing traffic to skyrocket from 40kb to 3MB (Note: This was before DSL and when 68kbit ISDN was avantgarde for internet access.) ... That's why that piece of code makes an 'unnecessary' copy of that XML object and deletes the old one.

    Likewise today, using WordPress, I see abysmal software architecture in the whole way WP is built. But not for a moment do I delude myself and think this could've been done from the very beginning. WP is historically grown and design decisions made back then might have had very good reasons, even from a software architects perspective.

    So, long story short, I'm not really ashamed of my code. At all.
    I know where it came from and what it did and why.

    --
    We suffer more in our imagination than in reality. - Seneca
    1. Re:Not really, no. Here's why ... by marekjm · · Score: 1

      So, long story short, I'm not really ashamed of my code. At all. I know where it came from and what it did and why.

      This puts things in a different perspective. Thank you.

      --
      Check out my virtual machine: http://viuavm.org/
  41. I am not ashamed of my code. by Ihlosi · · Score: 1
    However, my very first commercial project ended up an ugly glob of assembly with a little bit of C mixed in, which I hopefully will never have to look at again in my life.

    The product sold almost a million times and didn't cause any deaths, to my knowledge.

    My ability to produce readable, maintainable and debuggable code have improved signficantly since then.

    1. Re:I am not ashamed of my code. by OrangeTide · · Score: 1

      readable and maintainable code is somewhat overemphasized these days. Half the time so called maintainable projects should probably be written, and the other half of the time the nobody wants you to change a thing about the code because of the scary "risk" monster.

      I get a lot of not invented here sort of nonsense where a perfectly fine bit of software is discarded so that some new team can build it from the ground up. It makes me not want to go to the effort to design a reasonable and extensible API.

      PS - assembler is quite "debuggable", I usually don't have an environment where source level debugging works. (kernel, bootloader and on-chip firmware). A good manual and good tools go a long way to making something debuggable.

      --
      “Common sense is not so common.” — Voltaire
    2. Re:I am not ashamed of my code. by Ihlosi · · Score: 1
      readable and maintainable code is somewhat overemphasized these days.

      Well, in my line of work I've realized there is a fair chance of products coming back to bite me for a couple of years after they are released. Making the code maintainable is a sanity issue, since I'm the one who will be doing the maintenance if necessary.

      PS - assembler is quite "debuggable"

      Yes, if you stick to a few simple rules (like avoiding overly long functions and such), and if you use an architecture with an assembly dialect that's easy to understand (which wasn't the case in this project - delayed execution, pipelining and features like zero-overhead-looping might make the processor very well suited to certain tasks, but the resulting assembly is very hard to understand).

      In fact, the assembly dialect spoken by that particular DSP is so full of unusual things that the compiler only used about 40% of the instruction set.

    3. Re:I am not ashamed of my code. by OrangeTide · · Score: 1

      I don't really impose any particular rules, much of the code I go through was written by dozens if not hundreds of other C developers. Sometimes functions in the kernel can be very long, several kilobytes in some cases. Which is unfortunate but not impossible to debug.
      As for the dialect of assembler, I'm not sure what you mean. I've done everything from MIPS, to PPC, to ARM to x86-64. The only real confusion is gas or intel order for operands when dealing with the disassembler. Some of the branch registers in the more obscure architectures take some getting used to. You're kind of forced to know the CPU you are working on when you debug this way. I haven't done much with DSPs, but the GPU shaders I work on are quite unusual compared to a general purpose CPU. In my line of work (SoC vendor) knowing the architecture and reading assembler is already part of the job, so I'm given ample time to get up to speed on those details.

      My current project is 64-bit ARM (aarch64), but the hardware itself is a different architecture. There is a bit of firmware that dynamically recompiles everything from aarch64 to a custom VLIW. I don't bother doing the VLIW and [somewhat] trust that the CPU team already has done sufficient testing.

      There is probably not a general answer to any of the broad questions on best practices. What works at my company, in my industry, is not necessarily repeatable in a different industry.

      --
      “Common sense is not so common.” — Voltaire
  42. Big Brother by mrchaotica · · Score: 1

    I was working for a company that made pharmacy management software and helped implement support for Prescription Monitoring Program reporting. There is a gigantic amount of personal information that gets sent to the government any time someone gets prescribed a controlled substance (including personal information even of the person merely picking up the prescription, if not the patient).

    --

    "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz

    1. Re:Big Brother by MouseTheLuckyDog · · Score: 1

      You shouldn't have flushed it.
      In Illinois you are supposed to take it to the police. They have a drug dumping area.
      Flushing it, let's it out intto the ecosystem.

  43. Re:I'm not ashamed of it... by i.r.id10t · · Score: 1

    if
    (this_is_true)
    {
    print("hello world");
    }

    5 lines in 2 seconds...

    --
    Don't blame me, I voted for Kodos
  44. If they wanted quality code by ckatko · · Score: 2

    If they wanted quality code, they should have paid for the time to create it correctly in the first place.

    Since nobody wants to pay for quality code, then they get exactly what they paid for. Something that gets assembled as quickly as possible to maximize the return on investment.

    1. Re:If they wanted quality code by jmcvetta · · Score: 1

      I've had several companies tell me they were very interested in improving the security of their software. Then when I found some security issues and suggested we fix them, was told to stop wasting their time with irrelevant stuff. Most recent time this happened was 2 weeks ago.

      One company, a few years ago, was particularly bad. One of the vulnerabilities I'd pointed out was exploited a couple months after, resulting in the compromise of a server. That server had full access to a database full of HIPAA-protected patient data. Of course the company leadership denied left and right that the data was PHI (protected health information). But I've worked for other organizations that did take their HIPAA obligations seriously, read parts of the law, and this stuff super obviously was PHI. Also had data on a few patients in Massachusetts, making it subject to the somewhat draconian Massachusetts Data Security Law.

      FWIW, that same company's software also directly facilitates likely violations of several state's labor laws. I'm afraid I don't know enough about various state labor laws to say for sure - and some states have really, really bad labor laws - but the stuff they did was super shady. Basically amounted to shorting low-wage workers on their already meager pay. Which is exactly what the customers wanted.

      When I pointed out to bossman that this was probably illegal, and surely unethical, his reply was: "shut the fuck up and code, you sub-human peon!"

      Without a doubt the worst company I've ever worked with. In terms of leadership, ethics, and code quality. Naturally they are a VC-backed startup based in San Francisco.

      Not going to name the company here - no interest in getting sued for libel. But if you're a gubmint enforcement type, feel free to present yourself and your credentials, and we can chat. I post under my real name, you shouldn't have any problem contacting me.

  45. Re: I'm not ashamed of it... by Jeremi · · Score: 1

    Clearly you are unaware of the miracle of copy&update :)

    --


    I don't care if it's 90,000 hectares. That lake was not my doing.
  46. If you don't have one project you're ashamed of... by Pascoea · · Score: 2

    If you don't have at least one project you have worked on that you aren't proud of you probably aren't a programmer.

    Mine is a steaming turd of a purchase order request "system". Written in VBS inside of Excel, talking to a MySQL database back end.

    It's not pretty. It's not fast. It's not sustainable. But, it met the purpose of the request using the tools I had available to me. And it was better than what they were using at the time. 5 project managers all writing purchase orders, or not, off of their local computers. Most of the time the PO wouldn't get to the Accounts Payable person, and if they did it was usually a hard copy. There were no backups. Nobody knew how the database worked. Nobody knew how to re-install it, or where the source for it was. Many many dollars lost.

    I would have never imagined they would still be using that system, this was 8 or 9 years ago. I have a feeling that's how most of these embarrassments work, a fast and messy fix to an immediate problem that will be "replaced eventually" that never gets touched again.

  47. Re:I'm always proud of my code by OrangeTide · · Score: 1

    bugs in undeployed have zero customer impact.

    --
    “Common sense is not so common.” — Voltaire
  48. Programmers are not statesmen by Improv · · Score: 1

    It's great when as individuals we have the luxury of choosing where we work. I'm at a point in my career where I have that luxury and I use it. I'd leave a place that frustrates me enough, either in terms of mission, management, or coworkers. As a group though, a lot of us lack that choice, and even for those who do, when they step away the employer will just find someone else to deal with the crap they left behind, because funds are sustenance, we've all got to eat, and if there are spare funds to hire people, more people will keep entering the industry (it's not like other industries are exempt from this - they often have it worse).

    None of this means we should give up on trying to make the world a better place, for those of us who have that ideal. We just usually will lack the leverage to do much, like almost everybody else. And if we start with the idea that we're wiser, more ethical, or the people who are uniquely situated to debug society's ills, we're starting with a significant handicap.

    --
    For every problem, there is at least one solution that is simple, neat, and wrong.
  49. presumpuous! by Gravis+Zero · · Score: 1

    "We are killing people," Martin says. "We did not get into this business to kill people.

    Speak for yourself buddy! I have a counter for my kills. ;)

    --
    Anons need not reply. Questions end with a question mark.
  50. Re:I'm not ashamed of it... by mark-t · · Score: 1

    If you really typed that in only 2 seconds then you've got record-breaking typing speeds, hitting over 20 keys every single second. The fastest typist speed *ever* recorded was 216 words per minute, which works out to only 15 keystrokes every second, while most professionals cap out at about 70 or 80 wpm, which is between 5 and 6 keystrokes every second. To be perfectly honest, your claim is so far to the right of 5-sigma that it is more likely that you are exaggerating.

  51. Re:No, proud of - most times by K.+S.+Kyosuke · · Score: 1

    Celebrate ... style of loops and those lovely switch statements.

    Clearly my Scheme code will be unwelcome!

    --
    Ezekiel 23:20
  52. Yes by Laxator2 · · Score: 1

    I am ashamed of my code !

    My code is an abomination that must be ejected from the visible universe !

    We must send a message that will pass through the Big Crunch that will alert future universes that my code should not exist in any possible future !

    Etc.

    I am so ashamed.

  53. In the end... by mark-t · · Score: 2

    ... we are not paid to agree with our employer about everything we have to develop, we are just paid to deliver the requested work on time.

    If one has an insurmountable ethical issue with what they are developing for an employer, the only viable recourses are to find an alternative employer or to become self-employed.

    1. Re:In the end... by mark-t · · Score: 1

      In the end that is synonymous with one of the aforementioned options. You can't work for your employer if they are in jail.

      Obviously if you have a higher authority to complain to without losing your job then you have a world of options at your disposal.

  54. Just remember... by Jiro · · Score: 1

    If you are going to say "programmers should refuse to program unethical things", remember that this will be taken to heart by programmers who have ethics different from yours. It's not only going to apply to drug websites.

    We don't *want* programmers who are working on web sites for abortion clinics to do all they can to end the project because they have an "obligation" to avoid the "unethical behavior". (If you happen to be against abortion, imagine an example using a gun-rights website instead.)

  55. Re:I'm not ashamed of it... by tehcyder · · Score: 1

    Impossible task during an 8 hour day

    Right. On slashdot we have to get up in the morning at ten o'clock at night, half an hour before we go to bed, eat a lump of cold poison, work twenty-nine hours a day down t'office, and pay t'office owner for permission to come to work, and when we get home to our basement, our Mom kills us, and dances about on our graves singing "Hallelujah."

    --
    To have a right to do a thing is not at all the same as to be right in doing it
  56. It'll require legal enforcement. by quietwalker · · Score: 1

    Right now, the majority of people writing code are writing code because they're being paid to do so, either by individuals or more likely, a business.

    Those people, in turn, are not hiring programmers purely for altruism, they're doing it to achieve some goal, usually profit, increase in efficiency, and so on. They have to cope with estimating the curve for diminishing returns. They can figure out having a product that works 95% of the time, or one that works 96% of the time but costs 2x as much and takes 3x as long to develop may or may not be worth it. ... and ignore for now that developers are pretty bad at estimating project efforts as a whole, much less individual pieces of code.

    There's no incentive for these employers to pay their people to produce 'perfect' code. Even in the field of medical devices or self driving cars or a number of other systems, there's still a point of diminishing returns, and largely the business determines it based on market expectations, and adjusts it based on market reactions (no one will buy a self-driving car that crashes 1/5'th of the time, but they might buy one that crashes only 1 in 500,000 times).

    So developers aren't going to be given the time and other resources required to write perfect code. There will always be a balance between time, money, and quality, and outside of hobbists and a few industries, that'll never change. Unless there's some requirement that it change.

    I think it's very likely that in the near future, we'll have legal regulation regarding software that runs in certain environments; medical and transportation industry is very likely, but also public works like water or power management subsystems. On the other hand, there's really no reason to engage the entertainment or office productivity industry, and that includes cell phones and most personal computer apps.

    What form this regulation will take, I can't tell you, but due to the very nature of the process, it can be very difficult to detect flaws. My guess is that it'll be more of a fine-upon-discovery mechanism. Again, not much different than how we work now, with the added difficulty of a legal fine on top of market loss.

    Of course, were I in this situation, I would assign the rights of software bundles to do-nothing child corporations that act as defacto owners of the code, and then declare bankruptcy due to the cost of fixing the software AND paying fines. At the same time, child corporation 2.0 has a wholly compatible new app that will fix that issue...

    but that's me - I'm a problem solver, and this is just a paperwork issue.

  57. Yes deeply ashamed by aepervius · · Score: 1

    But that's because I learned a lot in the last 12 month going from Fortran 77 to Java. That process is called "learning".

    --
    C. Sagan : A demon haunted world:
    http://www.amazon.com/gp/product/0345409469/
    visit randi.org
  58. Reasonable Question by sycodon · · Score: 3, Insightful

    The Reasonable question: Are you ashamed of your code's efficiency, documentation, clarity and reasonable brevity?

    Unreasonable Question: Are you ashamed of your code because of some stupid SJW viewpoint?

    --
    When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
    1. Re:Reasonable Question by david_thornley · · Score: 1

      Are you ashamed of your code because of some stupid SJW viewpoint?

      All of the SJW viewpoints I espouse have been carefully considered by at least one allegedly intelligent person (me). They may be wrong, but they're not stupid.

      That being said, people do have moral codes, and can be ashamed of what they do to violate them. For example, someone working in Nazi Germany on something to save Jews might be ashamed (that's about as far from a SJW viewpoint as I can get).

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  59. And ... by fahrbot-bot · · Score: 2

    And dozens of people have already been killed by faulty software in cars, while hundreds of people have been killed from faulty software during air travel.

    ... the number of suicides by those early users of /. Beta may never be known ...

    --
    It must have been something you assimilated. . . .
  60. Robodial by Bizzeh · · Score: 1

    On my very first job as a programmer, got given a "special task", which i jumped at with it being my first job and wanting to impress.

    Ended up being a fax machine robo-dial app which had a list of over 2 million fax machine numbers, would cycle them all sending them a fax with our marketing information, and then loop back to the beginning and start again on the next piece of material. Would even switch the numbers it came from to disguise it was coming from the same place. Sent 2 million faxes every 3 days or so (using 90 outgoing lines).

    Was initially an internal app, but the company was so impressed with what i came up with, they packaged it and started selling it as a product.

    If you get robo-dialed faxes in the UK, its probably my fault...

  61. one day...kills tens of thousands by YrWrstNtmr · · Score: 1

    That ship sailed decades ago. See WWII + IBM + Germany.

  62. No by Virtucon · · Score: 1

    No, I write perfect code. It's always perfect because I wrote it. Don't bother reviewing it, it's perfect and works as designed. I designed it.
    Go away, you're preventing me from writing more code.

    --
    Harrison's Postulate - "For every action there is an equal and opposite criticism"
  63. Re: I'm always proud of my code by Dutch+Gun · · Score: 2

    Really lousy programmers can often otherwise be surprisingly knowledgeable in programming theory. I think it takes a certain type of person to be able to turn that high level theory plus program requirements into actual working code, all using a minimal amount of effort. The guy sounded like he believed every piece of code must belong to one of those patterns, or it wasn't fit to be published.

    One of the more valuable things I learned after I had already considered myself a reasonably competent programmer was how to avoid the tendency to over-engineer things (yes, a lot of us have the gang of four patterns book). There are times you don't need three classes and two abstraction layers when a simple one-off function will do. I think there's a real art in deciding how complicated to make your solution in the guise of making them future-proof, or alternatively, when to just keep things *simple*.

    --
    Irony: Agile development has too much intertia to be abandoned now.
  64. Overall, code saves lives by wvmarle · · Score: 1

    Sure it's going wrong now and then but overall I'm quite positive code saves lives. For every aircraft that crashes there are probably hundreds if not thousands of crashes that did not happen because of all the pilot aids. For all car crash that did happen, there are hundreds if not thousands that did not happen thanks to all those driver aids - including Tesla's autopilot. Software makes hospitals more efficient, helps to diagnose diseases and develop medication faster, may help doing a quick cross check on known side effects by combining medication, etc. X-rays come in faster, nearly real time. That all saves lives. That it is not perfect doesn't mean it's not effective, the few lives lost to software errors are nothing compared to the lives saved thanks to software.

  65. Sometimes... by skids · · Score: 1

    Whenever I find myself spending a lot of time coding compatibility so a closed source OS will work, I do feel the spring being sucked out of my step for prolonging the lifetime of said closed source product by improving its usefulness.

  66. No, not every job. Software freedom helps us. by jbn-o · · Score: 1

    Your response strikes me as typical of programmers in that they don't recognize how their work can affect a great deal more people than almost all of the examples you cite. With the possible exception of mishandling food, none of the other examples come close to affecting the same order of magnitude of people as programmers can.

    The recent VW emissions scandal is a perfect example: VW's proprietary software was used in around 11 million VW cars worldwide (that VW admits to) from model years 2009-2015. Comparable proprietary software was used in more cars of other makes and model years. VW's software apparently turned some VW cars into cars that never should have been sold. Other makes and models of cars are also showing bad signs of polluting too much and not being in line with regulations. The full scope of the damage has not been accounted for. Only centralized food processors working on very highly used ingredients have the potential for that kind of adverse impact.

    This creates a situation that kills us slowly instead of quickly by polluting our air in ways our (admittedly inadequate) regulation framework was designed to disallow. Proprietary software cheated those tests by behaving radically differently in regular driving than in testing mode. These cars should all be taken back by their manufacturers at full cost to the manufacturer, giving the current owner a complete refund of whatever they paid for the car, and the manufacturer's higher-ups should pay with criminal penalties and huge fines because this is a serious environmental matter. Programmers know their software is widely used (some programmers even value the wide reuse of their code) but rarely do programmers brag that their software treats people ethically and well.

    Being "aware of their moral compass" is too low a standard and something programmers have typically balked at besides. As Brad Kuhn points out, software freedom doesn't kill people, security through obscurity kills people, yet programmers today still debate the value of software freedom for its own sake instead preferring to either work on proprietary software outright, or choosing to value a non-free software-allowing right-wing corporate reaction to free software known as "open source". Read just about any /. thread today and you'll find plenty of technically literate people who balk at introducing ethics into the discussion, or try to explain away giving us all the means of helping ourselves via software freedom. Our best chance of finding and fixing the cheating car code is to require copylefted free software for all vehicles and make transfer of the complete corresponding source code and build instructions for said software with ownership of the vehicle. But we choose not to do our best motivated in part by those who would rather not enter into a moral discussion because they place business desires above how people ought to treat other people.

    One easy way to help fix this is helping those who help us. Today the Linux kernel is used in a lot of products that end up in people's homes, listening and watching them all the time via cameras and mics controlled with proprietary software. It's hardly a stretch to imagine that non-technical customers are being spied on without their knowledge or consent. It's bad enough that Linus Torvalds' fork of the Linux kernel allows proprietary software (as opposed to GNU Linux-libre which does not), but GPL violations are rampant. We can help the Software Freedom Conservancy by funding their efforts to pursue GPL violations, and I hope you'll do so. We owe the entirety of free software routers to comparable efforts, freeing code from Linksys which we can apparently reuse in many other routers. That freed software and its derivatives makes routers more trustworthy, improv

  67. Re:Ashamed for a different reason by thomn8r · · Score: 1

    ..patch one bug, re-submit.. 101 little bugs in my code...

  68. Re:I'm not ashamed of it... by HornWumpus · · Score: 1

    Luxury!

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  69. Civilization depends on us. by skaralic · · Score: 1

    Civilization depends on a lot of things. I'm sure that code makes it more efficient and makes it possible to do more things as the population increases but it's hardly a pillar upon which civilization is built.

  70. Re: I'm always proud of my code by Bengie · · Score: 1

    I've had the opposite experience. Projects that have been going on for years where the code was such a mess that bugs took months to fix, I would re-write from scratch in a month or two and never have another reported bug. Messy code is unmanageable and does not scale. It works for only the simplest of projects. And many times these projects turn into full time jobs because they are important enough to keep working, but messy enough that anything short of a re-write will stop people from complaining.

  71. Yes by shaitand · · Score: 1

    Not what I expected to see from that headline but I wrote code that was used by the ExtenZe people in their earliest days when they were spammers.

    As for programmers and the higher tiers of systems/db/network engineers we do actually have the power to enable terrible things, cause extreme harm through negligence, including loss of life. Industry is trying to grow our numbers as much as possible to keep salaries down but the world is probably a better place if we keep the club more exclusive.

    Computer professionals should probably have ethics boards and professional regulation like Doctors, Attorneys, and other flavors of Engineer. How do you feel about he possibility your spouse/child/mother might be flying on an aircraft tomorrow which is being piloted and air traffic controlled by software taken over by an H1B with zero experience and an Indian no academic standards and no 4 actual years required 4 year degree code monkey? A doctor can refuse to oversee military experiments modifying humans or testing chemical weapons because of ethical constraints. Should we not also be refusing to do harm?

  72. Re:No, proud of - most times by DickBreath · · Score: 1

    Remember when Red Light Traffic Ticket Cameras were a thing? I wonder if the person who shortened the length of the Yellow light in order to generate more revenue for the city is proud of the number of traffic accidents, injuries and possibly deaths they might have caused? Can that person say: just doing my job.

    --

    I'll see your senator, and I'll raise you two judges.
  73. Re:I'm not ashamed of it... by DickBreath · · Score: 1

    Does it count if I'm ashamed of a co-worker's code?

    --

    I'll see your senator, and I'll raise you two judges.
  74. Re: I'm always proud of my code by plopez · · Score: 1

    So in other words it's just a typical software project.

    --
    putting the 'B' in LGBTQ+
  75. Re: I'm always proud of my code by plopez · · Score: 1

    When I find myself saying "I can be really clever about this" I ask myself "*Should* I be clever about this?" Probably about 99% of the time the answer is "no".

    --
    putting the 'B' in LGBTQ+
  76. Code that got the SME's fired. by ers81239 · · Score: 1

    I was ashamed of my naivety when I worked on an freelancer-scheduling app for event planning.

    I was embedded with this team of about 15 people whose job it was to fill slots for servers, greeters, busboys, drivers, etc for a large event planning business. I sat with these people for 2 months, learning how they did their job and writing some software to help automate it.

    When I got done they fired all but 2 of the people because they weren't needed. I really didn't see that coming and felt terrible, especially since they had really helped me succeed at my job.

    --
    there are 2 kinds of people. those who divide people into 2 kinds, and those who don't.
  77. Re:I hate to admit it by plopez · · Score: 1

    I turned down a possible job at the naval weapons research center for exactly that reason.

    --
    putting the 'B' in LGBTQ+
  78. Re:No, but I'm... by __aaclcg7560 · · Score: 1

    So you're a glorified batch shell monkey. Which means you don't write code.

    I write PowerShell scripts at work. I write Python scripts, C extensions for Python, and hand code HTML at home.

    98% uptime isn't exactly "saving the universe" level of support, friend - that's over 1 week of allowed downtime in the course of a year.

    The 98% SLA means that I complete 98 out of 100 tickets ON TIME. The other two tickets go out of SLA because another department is sitting on their collective thumbs.

    Must be nice having a cushy job as a laptop jockey.

    I do work in government IT with a $3,000 Dell laptop. Of course, I'm paid 50% less than my Silicon Valley peers for being a public servant.

  79. Re:No, proud of - most times by Dread_ed · · Score: 1

    Was probably not coding that took place to change the light duration. Though it would be very interesting, from a prosecutorial/find-them-and-kill-their-children-in-front-of-them-then-remove-their-genetials-so-their-genes-are-eradicated-from-the-gene-pool-forever-for-doing-that-shit standpoint, to see exactly what steps were necessary for government employees and elected officials to so callously and intentionally cause human suffering and loss of life just to make some budget slush fund cash.

    I'm thinking it was just a simple slider or dial in some silly little GUI interface. Which raises the question, would responsible coding practices for the traffic control devices have resulted in a hard-coded minimum 3 second setting for yellow lights, which is the minimum recommended duration for yellow lights by the Institute of Traffic Engineers and required in the Manual on Uniform Traffic Control Devices?

    --
    When the only tool you have is a claw hammer every problem starts to look like the back of someone's skull.
  80. Re: I'm always proud of my code by molarmass192 · · Score: 2

    The guy we hired to replace him wrote it from the ground up in a month.

    You smell that? Do you smell that? Technical debt, son. Nothing else in the world smells like that. I love the smell of technical debt in the morning. You know one time we had a code sprint, for 4 weeks. When it was all over I code reviewed. We didn't find one of 'em, not one stinkin' bug. The smell, you know that stale pizza smell, the whole room. Smelled like ... a nightmare to come.

    - Software Architect Bill Kilgore

    --

    Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
  81. More ashamed of purpose than form by michael.o.church · · Score: 1

    I'm not ashamed of my code. If anything, I've been criticized for being too careful, in a world where sloppy, quick, ugly work is celebrated.

    Most programmers, in the corporate world, have no aesthetic sense and minimal mathematical knowledge. I prefer working with scientists and mathematicians and quants who think they're mediocre programmers, but don't try to do anything clever/stupid, over corporate coders who have to drag in 30 dependencies for some simple ETL task. Given the nonsense I've seen and occasionally been politically unfortunate enough to end up maintaining... no, I don't think I have anything to be ashamed of in terms of code quality.

    I am, however, embarrassed (my attitude is more one of guilt than shame) by many of the companies that I've worked for, and many of the purposes toward which I wrote code. When I came into the software industry, I really thought that I would improve lives. In truth, we're mostly harmful, and the negative reputation that we are developing as "techies" are well-earned. No, we don't deliberately choose to unemploy and harm people, but we don't fight back against our masters and that makes us complicit. We create mass unemployment and the obscene concentration of wealth (that mostly accrues to nontechnical people, because we programmers suck at collective action). We sell pointless virtual "goods" and "social media" status that no one needs, and then we use "Big Data" "science" to help corporate fucks find addicts. We make "business processes", like rich people firing poor people, more efficient. Oh, and while it's arguable whether we "elected Trump", there's plenty of evidence our products have been to the benefit of demagogues elsewhere in the world.

    I'm embarrassed to have been a corporate programmer. That cuts deeper than coding mistakes, which of course I have made as everyone does, but aren't in the same category. Missing an opportunity for tail recursion doesn't make you a horrible person. On the other hand, if you write performance monitoring/review software that results in factory workers getting fired, you're a fucking stain.

  82. Re:I'm always proud of my code by david_thornley · · Score: 1

    Sometimes efficiency matters. I work on proprietary CAD software that does other things in addition, and that can get REAL slow if we're not careful. I've worked on code that takes human inputs and puts out human-readable outputs and doesn't do much heavy processing or I/O, and efficiency just doesn't matter there. If you can take those agonizingly slow human inputs and respond to them within a tenth of a second for desktop software, you're golden, and any time you spend making it more efficient than that is wasted.

    --
    "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  83. I tried that. It didn't work. by Larsen+E+Whipsnade · · Score: 1

    The next employer was also a sleazeball.

  84. Re:Yes - who wrote this sh*t?!? Oh. Me. Ugh by terjeber · · Score: 1

    Yes - who wrote this sh*t?!? Oh. Me. Ugh. I realize that more often than I'd like.