Re: [ox-en] Software development is an ecosystem (was: the Deleuzian engineer)
- From: "Niall Douglas" <s_fsfeurope2 nedprod.com>
- Date: Wed, 28 Jan 2004 21:36:06 -0000
On 27 Jan 2004 at 16:45, Benj. Mako Hill wrote:
1. Will or will not an engineer who refuses to use certain
libraries, languages and technologies because of political reasons
tend on average to produce lower quality software?
It depends on the methods we using to evaluate the quality of the
software. You seem to calling for some sort of objective analysis of
software. This type of evaluation is only possible if we've got some
sort of universal consensus on the criteria that we're using to do the
evaluating. Otherwise, we'll come to different conclusions.
Clearly, there's not that consensus. You are very convinced that it
doesn't include a number of elements that other folks think are
essential. Your definition of what an engineer should be concerned
with is not the only one out there and I don't see any reasons why it
should be the best.
I take great care to never take a moral stance on matters which are
neither right nor wrong. I don't always succeed of course and quite a
few times I have been wrong myself. However on this particular matter
I feel quite assured, mostly because 18 months ago I was also a GPL
believer and found myself increasingly becoming uncomfortable with
the consequences.
Lets say I agree with this. My point is that you haven't gained
anything because you've simply moved the argument to what is or is not
a good reason which is just as contested as the original statement
because it's the same set of issues at stake.
No, we are getting closer to the knub of this. I should add that I
had a private email conversation recently with a very clever fellow
which lasted for over four months on these views until we finally
reached the core differences from which our opinions about software
differ (whether maths can describe the universe even if the universe
does not exist - I say yes, he said no). We covered a lot of ground
which is why I am doubly sure of my opinion on these issues.
On 28 Jan 2004 at 3:14, Robin Green wrote:
1. Will or will not an engineer who refuses to use certain
libraries, languages and technologies because of political reasons
tend on average to produce lower quality software?
Not necessarily lower quality if being able to fix bugs in a library
yourself is a key quality requirement. Rather than having to pay
Microsloth for the privilege of phoning in a bug report which will go
into an invisible black hole and may or may not ever be fixed.
Of course, though I should add that there are extensive unofficial
backchannels into Microsoft - I have personally found two bugs in
MSVC7.1. The reason I hate closed source libraries is because I can
even know where the bug is but can't fix it. x86 assembler is
inherently hard to patch :(
...I believe that on the _whole_, the useful commons of free software,
and the quality of that commons, is increasing. Certainly looking at
Java-based free software, that is unquestionably the case over the last
few years. And I would suspect that with more and more people coming
on-line and learning to code, and learning to code reasonably well,
even, that growth rate is probably increasing all the time as well.
And here in timely fashion you have just struck at the knub of what I
was referring to.
Software development is an ecosystem - lots of interdependent threads
interwoven together - both on the small scale (a single program) and
on the big (all software everywhere). Like any ecosystem, increasing
diversity leads to ever-increasing complexity and thus new emergent
strands of order. You can map biology books such as "Tree of
Knowledge" by Varela and Maturana directly to the software
development process.
Computer programming, as Fred P. Brookes says, is "an exercise in
manipulating complexity".
It is therefore provable that the greater the diversity of tools the
developer is expert at, the better the quality of code that developer
will produce. While it is not provable that the greater the set of
tools used, the better the quality - it can be shown that there is a
strong correlation between the range of tools used and the
"expertness" of the programmer.
Therefore I repeat my assertion, that the developer who rules out a
tool or technology for no good reason will produce on average lower
quality code.
But what is "no good reason"? I define that as being *entirely*
dependent on the task at hand. Some projects as Robin says will be
relying on immature libraries and so the ability to debug that
library at a source level is paramount. Other projects might need to
be compatible with VisualBasic, in which case you must exclude a lot
of operating systems and technologies which otherwise would be very
useful. Other projects still may have a programming team who only
knows C and no C++ - it would therefore be unwise to base the project
on C++.
"Good reasons" are operational constraints like resources, skills and
hard specifications (eg; if developing software to control aircraft
fuel, you'll want to write extremely defensively). A bad reason is
refusing to use anything other than GPL software because you are
ideologically opposed to anything else. That has no place in good
engineering.
What I really don't like about the GPL is it claiming to be free
software and yet preventing its reuse in a closed source product.
That is not freedom and there are contexts when closed source is
necessary.
(Most of these contexts are created by the use of copyright to
protect computer software. With a different legal support framework,
these contexts would almost never arise).
Even if that involves "reinventing the wheel" several times for each
technology.
What annoys me about that statement is that things like dynamic
memory allocators were perfected at least a decade ago yet a number
of major operating systems use very poor implementations. There is
one correct solution to most problems in computer software and
reimplementing inferior versions of them again and again is not only
wasteful, it's detrimental to all software.
If people spent more time inventing new idioms than repeating old
ones badly, the world would be a better place.
One man's reinventing the wheel is another
man's "listen to the customer and give him _exactly_ what he needs, even
if it is subtly different to the norm".
As I learned when working for EuroFighter, very often the customer
has no idea what they really want. They specify this system in great
detail over two years of meetings, I arrive to do the work and point
out that it's jibberish, makes no sense at all and so I must read
through all the technical manuals and try & figure out what they
actually want :(
EuroFighter is a worst case scenario, but as Fred P. Brookes said,
often the customer won't know what they wanted until you deliver what
they asked for :)
Cheers,
Niall