Re: Developer Accountability

[BrowserUk]

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.

[mirod]

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".

[herveus]

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

[BrowserUk]

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.

[Anonymous Monk]

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.

[BrowserUk]

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.

[Anonymous Monk]

I think that we are talking past each other. Yes, I understand very well the benefits of using mature components, the role of time and testing, the benefits of catching errors relatively early. These things are all good in theory, everything is good in theory, if you can just do it right and consistently.

The problem is that sometimes the Good Stuff™ comes at a cost. And that cost is that it creates extra work and more verbose code, which gets in the way of development. Sometimes the trade-off is worthwhile, and sometimes not. And often different people disagree on where the trade-off is justified.

See, for instance, the interminable debates on whether or not it is better to have dynamic typing or static typing. If you don't see why someone would possibly want to forgo the benefit of type-checks, then I suggest arguing with merlyn for a while...