Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Developer Accountability

by cacharbe (Curate)
on Apr 29, 2003 at 18:41 UTC ( [id://254047]=perlmeditation: print w/replies, xml ) Need Help??

If you are interested in technology and it's continuing role in politics and society as a whole, I highly reccomend Declan McCullagh's mailing list, Politech. Content is submitted and read by people ranging from lowly developers like me to some of the best minds in technology and politics from around the world, though that is so few and far between in combination. *grin*

This (continued here) is what generated this Meditation, which is actually my response back to Declan. Whether he publishes it to the list at large reamins to be seen.

"-The $165 million Mars Polar Lander probe was destroyed in its final
descent to the planet in 1999, probably because its software shut the
engines off 100 feet above the surface."

If I remember correctly, this wasn't, technically, a software error - it was an architecture error. In this case, the software/firmware did exactly what it was designed to do; it was the two design teams that did not communicate correctly on a very important issue - Units of Measure (Which is why all good high school physics teachers pound units into your head).

One piece of software was calculating with one method and passing its results off to another, which was calculating assuming a different units type. I know it's a fine line, but it's not like a memory leak or similar 'bad programming practice', the software was doing exactly as expected as designed.

Whatever. Talk is cheap.

What I didn't read in this article (as with the hundreds of others before) is how to implement an accountability structure that doesn't demolish innovation and put the fear of having a free thought into the head of every developer under the sun (or Sun, for that matter). Do we create a warranty system for the users? How is it implemented? Can we sue the software company? The implementer? The guy that wrote the code under a strict and irresponsible deadline that was set by management who usually has little or no development experience and will accept pressure from 'customers' to deliver over pressure from their own staff regarding quality, design and safety?

Personally, I think that the system is calming down, and the noise is starting to filter out. I think that like the automobile industry, manufacturers are beginning to set up their own recalls (patches, versioning, etc) in a similar fashion. You can get extended service plans with most enterprise level software (and most desk top level ones as well).

However, what you don't see is a public that is appreciative or even vaguely knowledgeable regarding the effort that goes into the magic of "You've got Mail! (tm)"

They pop the hood on their car and are intimidated by the 'new' technologies of drive by wire, fuel injection, ABS, auto traction control, etc, and are forgiving of a product life cycle that only sees updates once a year AT THE MOST because they have something physical that they can look at and say "Yup, I see, it, I don't get it, must be tough to do". Some platforms undergo changes at such subtle rates that the only difference to the user is a slight packaging change.

Also keep in mind that aside from the add on electronics that mean nothing to the actual function of the automobile (We call them "Bells and Whistles" in the software industry - like A/C, an audio/video system, turn indicators, interior lighting), the interface to the automobile is two (maybe three) pedals, a wheel and a shift unit (either manual or automatic).

But software... now, software is magic.

"Any sufficiently advanced technology is indistinguishable from magic" (Clarke's Third Law).

It makes writing a letter simple, changing and deleting content a snap. Formatting and printing, changing font styles, size, COLORS...Cake. And putting it in an envelope is reserved for only specific correspondences, the rest, email.

I don't know what it is about software, but people want their new release almost as soon as the CD/DVD begins whirring on the install of their current product. They'll drive a 57 Chevy with pride and spend thousands to get it running, but they'll be damned if their latest release of Quake renders blood-splatters across their 21" flat screen monitor without anything less than life-like color and accuracy.

It has to be better, faster, with a better GUI feature set (did I mention three pedals and a wheel yet?), more robust memory management (there's only 2 gig addressable, and I have 37 other applications running, you know), and I want it before your current projected release date. If I'm on the beta list, I'll get upset if it crashes my machine, and if I try to run it on old hardware, I'll expect _you_ to figure out why and how to fix the compatibility issues I created because I clamored for the new software, but am unwilling to upgrade my hardware to meet the needs of the 'feature, content rich' interface you required.

A good architect will know (because it's what we're taught) that there should be three ways to get to any function in software. Three. (How many gas pedals are there? Steering wheels?). Because no two people think about function the same. In honestly, it's that we haven't tried to come up with standards that deal with expectation and change management, so instead of creating a paradigm, we allow the user to dictate how we develop.

It's definitely a give and take method to implementing magic.

Granted, in the auto industry, there are focus groups and Q&A's, driver feedback, warranty and quality metrics, blah, blah, blah...but in the end, all of that goes to enhancing the 'Bells and Whistles'. Because we still use three pedals and a wheel.

When Neumann's group worked with NASA on software for the
space shuttle, developers were so careful about bugs that
they produced just three lines of code per day, an unthinkable
pace in an industry where a major application may have a million
lines of code."

If only the adhesives group was as meticulous.

I'll argue that not reusing strong code is the root of many of our issues today. This lack of reuse, brought on by an industry climate rife with IP mongers (lawyers) looking for the faintest breath of copyright infringement has kept the idea of a code or best practices data store out of the mainstream, thus creating a continuous (sometimes erroneous) re-solving of similar problems throughout the industry.

Look at a strong community of practice site like perlmonks.org. With environments like 'Snippets', 'Catacombs' and 'Tutorials' (not to mention the primary function of asking a perl question and getting many instructional perl answers), you begin to see good code packages being designed, broken and reborn as functional units which then are many times promoted (in whole or in part) to package status on CPAN or similar archives.

This type of practice GREATLY increases the robustness and functionality of code. By exponentially extending the number of people that try to implement a code base in different ways throughout its development lifecycle (thus, testing), you start to ferret out problems that the designers may have overlooked. This peeling away of layers happens at a much faster rate, and although slower than the "Throw a bunch of coders at a. - release, and b. - bug management" it is faster than three lines a day (most times). It also creates a stronger planning cycle. I don't know how many projects I have been shouldered with where the planning was thought of as a secondary need, rather than a primary focus. The observation is usually, "If I wasn't in my seat coding, I wasn't being productive". How do you explain that two extra weeks of planning now could save us four weeks of change and bug chasing on the back end?

To someone who only wants to see results (and I guess even negative results are results), you can't.

"Yet computer code could be a lot more reliable _ if only the industry were more willing to make it so, experts say. And many believe it would help if software makers were held accountable for sloppy programming."

I'd like to fine tune that a bit and say:

"Yet computer code would more reliable if only the consumers were more willing to let it be so, and it would help if software coders were allowed to do anything beyond sloppy programming."

It's change and expectation management, a lack of proper development methodologies and good managers to help implement them, a product complexity so much beyond anything that the consumer has ever before consumed on platforms changing faster than code can be written to optimize on them, etc, etc, etc.

Who's accountable?

"If software makers haven't done the best job, consumers are hardly blameless. We have long favored flashy products over reliable ones.
"That's what we pay for," Guttman says. "We say: `Give me the phone that takes the picture. Don't give me wireless security!'" "

As a developer, I'd personally like to point the finger at the consumer, but not only am I at their mercy I am one of them as well, so I cannot. It's Ouroboros, a snake eating its own tail. We, as a consuming public will not slow, so we, as a developer cadre, must do our best to stay in step with the speed and breadth of advancement. And in most instances, quality will suffer.

Kaner has the right of it, as a first step, I think. We should open our doors, and reveal our faults. As an open source advocate, obviously I feel that we should give access to the code as well, but not all need agree with that for this first step. Just agree that we should TELL the consumers when there is a potential of their gas tank exploding in the event of a rear end collision, or that they are at risk of revealing sensitive corporate information if a certain combination of products is used.


What do you think? Obviously there need to be checks and blances in place to protect the integrity of data and the safety of people that rely on software, but how do we, as developers, help to find and implement them?

I think it is time for us to start insisting on Q&A and development life cycles that mean something. I'm NOT suggesting some kind of QS9001 for code, heavens no, but can we begin to raise the integrity of what we do by driving the quality of our product vs. the fastest time to market? Can we begin to help the consuming public with expectation management and change management?

Tough subject.

C-.

---
Flex the Geek

Replies are listed 'Best First'.
Re: Developer Accountability
by dragonchild (Archbishop) on Apr 29, 2003 at 19:08 UTC
    Wow. An excellent Meditation that touches on many, if not most, of the sore points in our profession. I'm only going to elaborate on one point.

    I think it is time for us to start insisting on Q&A and development life cycles that mean something.

    How would you suggest doing that if you're in a company whose CTO blames the developers for shoddy work when each developer has 27 days from being handed requirements to delivery into production, regardless of the scope of change? (Yes, I've been in that situation.) Expectation management is not just between developers and consumers. It's between developers and "Other", for all forms of "Other". It's often between developers and other developers.

    Furthermore, just like in any industry, there are bad programmers and there are lazy programmers and there are disinterested programmers. There are programmers who've been told "You're the programming guy, go fix XYZ before the demo this afternoon." XYZ happens to be in a language you don't know on a platform you've seen once before. But, you're the programming guy, so you need to solve it. (And, yes, I've been in that position, too.)

    In my opinion, Management is the one that is causing the issues. Now, they may be doing so because consumers have been conditioned to expect stuff to be half-assed, so management has to beat the next guy who will make his programmers do things "The Wrong Way"(tm). The only way to do that, it seems, is to be "wronger" than the next guy.

    So, I guess the expectations that need to be managed isn't to reduce the "Gimme more features" cry but to increase the "Gimme stability" cry. We need to make J. Q. Public realize that the best features are useless unless the foundation works.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      Oh, I know all about being the one that's blamed for management mis-expectation (see any or all in my Drama series). It is yet another Ouroboros. I guess all I can say is that as we like-minded developers move forward in the ranks, begin to manage, project manage, lead and architect, we can begin to effect the correct change on those that follow us, and those above that have learned to listen to us.

      I've been slowly integrating my thoughts on project management (that there should be some) and expectation management (that we should help dictate time lines, etc, since we know how the hell to actually do our job) around my work place, but there is still such a long way to go.

      C-.

      ---
      Flex the Geek

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Developer Accountability
by chromatic (Archbishop) on Apr 29, 2003 at 20:50 UTC
    How do you explain that two extra weeks of planning now could save us four weeks of change and bug chasing on the back end?

    I don't.

    After reading Pete McBreen's Software Crafstmanship, I think there's a big difference between the kind of software NASA writes and the kind of software most of the rest of us write.

    Yeah, they did make a really really big mistake by not communicating with each other -- but I don't think adopting the rest of their development practices is going to be very effective for business and open source development.

    I think the real problem is pretty simple. We're not solving the users' most important needs. The solution to that is also pretty simple. Get your customer involved as soon as possible and keep him involved.

    Imagine how much time and effort you could save if you could ask the customer, "What's the most important thing this software could do that we could implement in the next week?" Suppose then you implement it and the customer is right there to say, "Not quite right, just a little different, okay perfect!"

    Call that better QA or development lifecycles if you like. I'm just convinced that getting feedback early and often and acting on it all the time is a much better way to write good software than hoping your one-, three-, or six-month-old plan got everything right.

    There are lots of ways to handle the rest of the issues -- testing, refactoring, pair programming -- but the way to provide useful, effective software is to be in constant communication with the actual customer.

      I agree that the customer should be involved from the beginning, and that a project plan at it's end is never what it looked like in the beginning or even half-way through, but I also believe that you should have a plan. Many development groups don't, and it shows.

      If the life cycle is(briefly):
      • getting specifications
      • planing
      • coding
      • testing
      • rinse repeat

      Then you are coming back around to getting specifications, but you are also coming back around to the planning stage.

      Too much code that I see being written is being written with sketchy specifications and planning with too many changes during the code and test phase because the specification and implementation plans are poorly thought out and implemented. I don't know, maybe it's just the environments that I have been in, but I get the feeling that it is the same all over.

      I always get a top 20 list from a customer (for instance), and then we narrow it down to five or ten features that are the most important, rank them, and then add others as we hit our milestones. I'm not ignorant to changing specifications, or what good design specification, customer interaction and feed back are, I'm just suggesting that it needs to happen on a larger scale. And part of that communication also works toward expectation-management, which is a key factor, in my opinion. No going off into a sealed chamber to create, but everything done in front of the customer, so that their opinion counts, but it is shaped by what they see as possible and what is being accomplsihed.

      *Shrug*

      C-.

      ---
      Flex the Geek

Re: Developer Accountability
by BrowserUk (Patriarch) on Apr 29, 2003 at 21:07 UTC

    god forbid that developers, in the corporate or individual sense of the word, will ever become succeptable to the litigious nature of modern western culture. Woman sues McD because she burned her crotch will driving with a cup of their coffee between her thighs, and it didn't explicitly state that it was hot. So now the rest of us have to put up with luke warm coffee.

    That said, I also think that the "This software is not warrented, explicitly nor implicitly as fit for any purpose" clause is a hugely detrimental cop-out, very damaging to the industry and the profession. Imagine a car that came with a "this car may not go around corners safely" sticker.

    I whole heartedly agree that the best route to affordable, timely and warrentable (though not necessarialy warrented) software, is code re-use. Re-used components become more reliable over time, and reliable components greatly contribute to reliable applications.

    However, I think that before "re-usable code" or "software components" will make a real impact upon the quality of applications, several things will need to come into being.

    • There will need to be a standard defined for the modularisation of such components.

      This would need to take the form of a standardized way of documenting the input and output parameters and the logical/mathematical relationship between the full ranges of valid inputs and the resultant output.

      The standard would need to lay down a method of defining -- precisely -- the acceptable range of all inputs, the defined range of outputs, along with a standard mechanisim for reporting and handling exceptions. This is sometimes referred to as a contract.

    • The standard would have to defined such that any component, regardless of its source language, originating or target platform, can be called by any other component.
    • The final piece of the jigsaw is the runtime enforcement of the contract. Without this, the contract will have only advisory status and will be subject to the vagaries of "best intentions".

    An 0-ba nut from one manufacture will fit a 0-ba bolt from another because of such defined component standards. Similarly, watches keep (roughly) the same time, tyres fit wheels, plugs fit sockets, paper fit envelopes and printers, clothes and shoes almost fit people--its a one-sided standard. Etc. etc.

    Given that these three could be satisfied, then I think that it would be possible to start writing reliable, warrantable software at a reasonable cost of development.

    The key, I believe, to making this work, is to delegate the responsibility of runtime enforcement of the input parameters to a function or method of a component, to the hardware.

    Given the increasing power of todays processors, very large instruction words and super-scalar arcitectures, it should be eminantly possible to define an architecture independant, standardized mechanism for declaring the formal parameters of a function or method to the processor, along with the constraints and assertions that need to be applied to them. The same is true for a standardized method of presenting the passed parameters to the processor. The processor could then enforce the contract between the caller and the called, efficently and reliably, at the hardware level.

    The process of independant validation of the contract enforcement of any particular piece of hardware is considerably simpler and cheaper than doing the same for every piece of software written. With a standardized, cross-vendor calling mechanism defined, the verification of compilers and interpreters against this standard would also become a realistic proposal. Once the compilers and interpreters can be validated, it reduces if not completely removes the various commercial and legal risks and prejudices against re-using components from third party sources. With standardisation at the hardware level comes language and platform independance, and the removal of many barriers.

    It would become possible to write applications in such a way that the end user could purchase or download individual components from any source and the application could simply use them. Whether the components were obtained in binary form for their specific platform, or in source form and self compiled, the application would simply use the local copy of the component through load-time or run-time binding. This would also have the effect of introducing competition at the component level, reduce the distribution size of applications, and allow the appropriate language to be used for each component without the fear of interoperability problems.

    Given that the latest hardware is getting close to the point where it is possible to render almost film-quality 3d graphics in real-time, the next generation (or maybe the one after that) should easily have enough performance to allow for runtime contract enforcment of parameter restraints without imposing an unacceptable burden in most applications. Back in the days of Pascal, it was possible to have the compiler add code to perform runtime array bounds checking. Unfortunately, this was usually disabled in production code because of the performance penalty, but the hardware has moved on a long way since then.

    My thoughts on this go much deeper and have evolved over a long time, but this probably isn't the right place for taking them further.

    One thing that is perl related, is that given the flexible typing mechanisms presented in the last Apocalypse, and the apparent cross-language capabilities of the parrot engine, it would only(!) require the addition of constraint specification mechanism to the language(s) and (optional) run-time checking mechanism in the engine, to approach a software simulation of the possibilities. I still think that the hardware element would be required for it to have a real effect on the reliablility of software in general, but the simulation in software would be a good way of (dis)proving my theories.

    Counter-points to my thoughts eagerly and gratefully received, via a different communication mechanism if it is too far off-topic for this forum.


    Examine what is said, not who speaks.
    1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
    2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
    3) Any sufficiently advanced technology is indistinguishable from magic.
    Arthur C. Clarke.
      Woman sues McD because she burned her crotch will driving with a cup of their coffee between her thighs, and it didn't explicitly state that it was hot. So now the rest of us have to put up with luke warm coffee.

      Now you've hit one of my pet peeves! I am so sick and tired of this being used as a proof that something is wrong with the US legal system. The truth is that this case proves that said legal system does work. Check you facts: a quick overview, and a more lengthy discussion. This suit just shows that companies should be accountable for their decisions. I would very much like my own country to follow that practice instead of just letting it go and people saying "c'est la vie".

        Howdy!

        I also recommend The TRUE Stella Awards for a broader look at odd lawsuits with sources cited to back up the examples. Also a debunking of a widely distributed list of "outrageous" lawsuits that are completely fictional.

        yours,
        Michael

        I just wrote a long and rambling response to your point, but decided that the it was simply too far OT for this forum.

        I will have more care in my choice of examples to support my arguments in future.


        Examine what is said, not who speaks.
        1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
        2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
        3) Any sufficiently advanced technology is indistinguishable from magic.
        Arthur C. Clarke.
      You are trying to solve the wrong problem.

      Fine. We now have a way to rewrite software to be able to crash it immediately if a function is called incorrectly. We can't guarantee that the function works as documented, or that the caller understood the documentation and is calling the right function. We can't guarantee that caller or callee is writing to a spec that remotely resembles what the user thought would happen. And we don't have a solution for the problem where you get half of your code written and then find out that you need to change the spec.

      The fact is that software development is all about management of complexity. Telling developers to accept a level of complexity across the board that may or may not help them much is more likely to compound the problem than to assist it.

        You are trying to solve the wrong problem.

        Obviously,I disagree. As I indicated, my own experience that acheiving maturity in software is the key to reliability, hence the (now old) adage that you should never use a x.0 release of anything for production purposes. And the key to maturity comes from the ability to re-use components. Decoupling of components through clearly defined and enforced interface contracts removes many of the barriers to code re-use.

        We now have a way to rewrite software to be able to crash it immediately if a function is called incorrectly.

        Put that way it doesn't sound so useful, but it is.

        By "crashing immediately", it becomes painfully obvious that the program in incorrect. Its when coding errors are not detected that they make it out the door into production systems that cause most harm.

        Failing reliably and early is the main benefit of using strict.

        We can't guarantee that the function works as documented

        That guarentee comes from maturity. The more often and the more widely a function is used, the more likely that any errors in the functionality will be detected and corrected. The maturity comes from reuse. I think this is the key to open-source developments success.

        or that the caller understood the documentation and is calling the right function.

        Clearly defined interfaces and enforcement result in early failure forcing the developer to discover his error sooner rather than later.

        We can't guarantee that caller or callee is writing to a spec that remotely resembles what the user thought would happen.And we don't have a solution for the problem where you get half of your code written and then find out that you need to change the spec.

        That's a mixed metaphor (without the metaphor:), and a different problem. This is more a bespoke software than a packaged software problem.

        You can't fixed a bad specification at the code level. You either code to the spec and hope the spec is right, or you throw away the spec and the analysis (and the analyst while your at it) and use RAD to get the user to direct and approve the code step by step.

        That doesn't rule out the practice of code re-use, nor the benefits derived from it. In fact, using RAD in conjunction with a readily available set of components is far and away the cheapest and quickest way of doing bespoke development. Enabling the developer to concentrate on picking and gluing the components together rather than needing to design and code the infrastructure from scratch each time.

        This is exactly what HLL's are all about and Perl + CPAN in particular. The only fly in this ointment is that lack of consistancy in the quality of the documentation and code... (I'd also add a lack of coherence in overall design at the CPAN level, but that's a personal windmill).

        The fact is that software development is all about management of complexity.

        No argument there. And the key to managing complexity is "divide and conquor", "decomposition", "de-coupling", "objectifying", "componentisation". Call it what you will. The solution to complexity is to break it into smaller, soluble pieces.

        The problem is, the more complex the problem, the more pieces are required. The more pieces, the more interfaces there are. These interfaces then become a part of the problem. Take a box of tried a trusted components and try to slot them together to make a complex entity and it's the connections that are the key. In the physical world, trying to screw a 3/4" bolt into a 5/8" nut makes getting it wrong pretty hard.

        Every electrical connector these days is designed such that it will only connect one way. Do electricians, electronics engineers and technicians feel slighted by this idiot-proofing? No. They are grateful that another source of potential errors is removed from their daily lives.

        Telling developers to accept a level of complexity across the board that may or may not help them much is more likely to compound the problem than to assist it.

        I do not understand this assertion at all? I don't know where you are coming from or how you got there.

        Summary

        What I am advocating is the software equivalent of the one-way-only, keyed connector.

        I doesn't alleviate the need for proper design, nor reduce the complexity of complex systems, nor free the developer from due care.

        What it does do is enable complexity management through decomposition, and reliability through code re-use, by fool-proofing the connections between components, thus removing one of the perpetual problems of software development by moving it into the hardware.


        Examine what is said, not who speaks.
        1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
        2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
        3) Any sufficiently advanced technology is indistinguishable from magic.
        Arthur C. Clarke.
Re: Developer Accountability
by toma (Vicar) on Apr 30, 2003 at 07:50 UTC
    Accountability comes from caring about your customers. Care can be enforced with laws or process, but it is better to sit across from your users when you eat lunch. At lunch we are holding knives, and not harming each other. Leveraging this fundamental experience of civilization improves code quality.

    I would prefer to use buggy software from someone who cares, and will fix it for the asking, rather than software manufactured in an optimized development process executed by an indifferent, interchangable staff.

    The challenge to the SEI model is accounting for programmer motivation.

    It should work perfectly the first time! - toma

Re: Developer Accountability
by chaoticset (Chaplain) on Apr 30, 2003 at 16:12 UTC


    I've spent time comparing the two industries myself (with virtually no concept of history, mind you, so I'm probably very wrong).

    Original cycles in the car industry looked very much the same, with the major differences being cost and size. Previously, I had never considered size as a major factor, but now that I think of it, the possibility occurs to me that people are using a somewhat outmoded criteria (how big something is compared to them) to determine how threatened they should feel by it. Cars are bigger than us; computers less so.

    Probably the easiest way to figure out if this is even remotely valid would be to take a look at the differences between people's attitudes toward laptops and desktops, since there's a size difference. Still, they're both smaller than a person -- perhaps the difference in attitudes between mainframes and desktops?

    Bizarre archaic size concepts aside, I've also been thinking about stupid customers. (And this is something I think anybody who's ever worked at any business has a fair chunk of experience with.) Stupid Customer = Instant Gratification + Lack of Understanding. When a stupid customer makes a request and is provided whatever they request, other customers usually get the option of having it too -- and if the only customers who feel strongly on the issue are all|mostly stupid, then you're going to have an industry standard stupid option. If that stupid option is cheaper and enough people feel vehement about it, they cause the rest of the customers to get screwed because companies start taking the stupid option.

    I have been told (and I'm not certain it's apocryphal) that corrective lenses were once used to correct your vision, that you got a set of them that the doctor had and went home. You wore the first set for a few weeks, then moved to the next strongest, etc., and eventually you didn't need them and brought them back to the doctor. The problem with that for an industry? You sell a few sets per doctor and that's it.

    And it can just be envisioned that a stupid customer eventually just ignored the doctor's advice, wore the strongest ones, and kept them permanently, at a great charge. Doctors noticed they could sell them, companies noticed doctors were selling -- next thing you know, Pearle Vision centers.

    Again -- I don't know if this is apocrypha, but assuming for the moment it's true, it could be described as an economic force punishing everyone else for the stupidity of small groups.

    Roughly the same concept would apply in software. If the person taking feature requests is unwilling to explain to the customer why a stupid request is stupid, or the customer is uneducated and well-rewarded for their stupidity, then you're going to end up with stupid requests, you're going to end up with stupid software, and you're going to end up with (worst case scenario) a stupid industry standard.

    Standard disclaimer applies: I don't have the faintest clue what I'm talking about, this is all conjecture, IANAL, etc., void in Utah.

    -----------------------
    You are what you think.

Re: Developer Accountability
by Anonymous Monk on Apr 30, 2003 at 13:31 UTC
    And why should anyone listen to us? More precisely, if we say to do one thing, and profitable behaviour is something else, expect people to do what is profitable. And that is what Declan misses. Unless you have incentives that make the socially desired behaviour also the profitable one, you will see companies consistently misbehave.

    For background read Why Information Security is Hard - An Economic Perspective. (Taken from Economics and Security.)

      So true. One of the reasons why I said "Tough Subject"

      And just for clarification. Declan didn't write it, he distributed it. The article itself was written by PETER SVENSSON AP Technology Writer

      C-.

      ---
      Flex the Geek

        Just for further clarification, where I talked about what I think Declan missed, I was referring to his comment at the top of this.

        As for the article, it was pretty generic for the brand. The one thing that stands out in it is the mention of the Sustainable Computing Consortium. I mistrust their goals. (See also.)

        For those who didn't follow the links, the SCC is obstensibly a consortium of companies which are trying to create programming standards to assist the maintainability of software. A laudable goal to be sure. But to many cynical people it seems more like the real purpose is to create pressure to allow it to set the agenda on development standards for the goverment, allowing its members to get a significant edge on lucrative development contracts. Which is a much less laudable goal...

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://254047]
Approved by dragonchild
Front-paged by dragonchild
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (5)
As of 2024-03-28 16:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found