On Thu, 28 Jul 2005, Roy T. Fielding wrote:
> On Jul 28, 2005, at 2:46 PM, Bryan Cantrill wrote:
>
> > For an operating system, the constraints of existing interfaces are a
> > _technical_ problem, _not_ just a business problem.
>
> That is absolute rubbish. A technical problem is something for which
^^^^^^^^^^^^^^^^
No it's not absolute rubbish - and describing it as such does a great
dis-service to those talented engineers who have worked on it. And to
those that understand it.
> a technical solution can be created to resolve the problem. An
> interface constraint is simply a decision not to change some aspect
> of the interface. It is no more of a technical problem than deciding
No it's not "simply a decision not to change some aspect of the interface"!
It's taking the time and making the extra effort to see if a technical
solution can be arrived at without breaking backward compatibility. As
such, it forces a more disciplined approach to software engineering, rather
than a cursory: "I don't like this interface - so I'll simply change it and
then build my software on top of that change". The latter is called
hacking - or as I would describe it to most people - thinking with the
keyboard, instead of thinking with your brain.
> whether you want to develop a word processor or a web browser.
Absolutely disagree. And trivializing it like this demonstrates a complete
lack of understanding.
Let me back this up by providing you some real world examples of how
interface stability adds value. And I will describe it from a developers
perspective and not from a business perspective.
With Solaris I have code that is 5 and 6 years old, that was originally
developed and tested on Solaris 2.6 - and I simply move the binary (x86 or
SPARC) onto a system running Solaris 10 - and it runs as designed. It
passes the original test suite. If I desire, I can recompile it with a
newer C compiler (a commercial compiler from Sun, or a newer version of
gcc), and guess what.... it runs and passes the same test suite - only it
runs considerably faster! And it runs in 64-bit or 32-bit mode without a
single modification!
So, as a developer, I'm free to invest my time developing new software or
adding new features to existing software and I don't have to waste my time
having to "fix up" code to get it to compile on a newer Solaris release or
with doing mass search/replace operations on code and reworking code to get
it to pass an existing test suite. This type of "silly work" is a complete
waste of time and adds no value to a developers skill set or to the end
users experience.
What does that mean to the users of the code? It means that if they change
platforms or operating system releases, they can very quickly have a new
release of the code that runs without introducting any new bugs. The only
difference they'll notice, it that it was provided within hours of the
request and it runs considerably faster on their new hardware platform with
their new release of Solaris or OpenSolaris.
Looking ahead in this thread, you infer that there is something inherently
wrong with maintaining interface compatibilty and that it stifles
innovation. I'd like to point out that Dtrace proves that interface
stability can be maintained and proves that innovation and entirely new
capabilities can be added to (Open)Solaris without disruption. And I mean
disruption from the developers perspective and from the users perspective.
I did'nt have to change one line of *my* code because Solaris 10 introduced
Dtrace! Or to be able to take advantage of Dtrace to find the silly
mistakes or bottlenecks in my code!
And talking of innovation - Dtrace has solved a software problem for
developers that has been "on the shelf" - for anyone to solve - for 20
years. It has allowed users/developers to find and fix bugs and
performance bottlenecks within their software that have plagued them for
years. That has resisted their best concerted debugging efforts for years.
That has caused disruption and service outages for users for years. And
this can be done with the actual software running in the production
environment without any service disruption.
So my points are very simple:
- interface stability add significant value for the developer and the user.
- interface stability allows and promotes productive use of developer
resources.
- interface stability can *usually*, not not always, be maintained with a
little extra "thinking with the brain" effort.
- interface stability does not stifle innovation - but actually allows the
developer to concentrate their time on adding features/value and exploring
innovative tools and techniques.
- interface stability requires some extra effort. There is no free lunch
with software or with any other engineering discipline.
- the extra effort required is not a significant barrier - it's more of a
mindset change.
> Discovering if an interface would be changed by an integration is
> a technical problem. An ARC review should certainly be looking for
No - discovering "if an interface would be changed by an integration"
implies a reactive, slap yourself on the head _mistake_. The ARC process
is designed to predict requirements and issues early in the technical
software development process and assure that integration is smooth and
almost a "no brainer".
> such changes. It is fine for incompatible changes to require a major
> revision number to change, but the decisions on whether or not to
> develop such a change and when to release new major revisions
> are *business decisions*. Those are Sun-internal Solaris decisions,
> not OpenSolaris-wide decisions. Therefore, OpenSolaris can let new
> development happen on an unstable "next major release" branch and
> only worry about the interface constraints when those changes are
> proposed for back-porting to a stable branch.
>
> > New interfaces
> > obviously don't have these constraints, which is precisely why they
> > must
> > be developed so carefully -- today's new interface is tomorrow's
> > constraint.
>
> They have to be released carefully. We can have 100 monkeys
> typing away at the interface and that is fine -- it costs nothing
> until someone asks "can I release this as version x.y.z?", at
> which point the new interface is going to have to satisfy whatever
> constraints the community wants to place on it.
"100 monkeys typing away at the interface" implies a complete hacker
mentality to me and it the very antithesis of software engineering.
Software development is an engineering discipline - and when treated as
such, provides a stable, predictable and correctly behaving Operating
System that the developer can deliver his/her applications on with complete
confidence. Or they can extend/expand the Operating System itself knowing
that they are adding value for *every* user/developer in the community and
that they are *not* a cause for developers to waste their valuable time
recompiling/fixing software and discovering/fixing new and devious bugs.
Further I'll predict that any software developer who truly cares about
their craft will benefit greatly by taking the time to understand the
significant payback they'll accrue by putting in a little extra effort to
maintain interface compatibility. It's not an easy sell - but I guarantee
to any developer that makes the effort, it'll make them a significantly
better software engineer and provide them with skills that they can/will
leverage throughout their career (assuming that they have chosen software
development as their career).
Regards,
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134
OpenSolaris Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
