Re: Bad programming practices encouraged.... namely VB!
> That's a real shame. Be careful your employer doesn't catch on. Most
> code owners like to believe (real or illusion) that their code assets
> can be reused.
Well I disagree. Here are some of my thoughts on the matter so you know
where I stand. This is a 1st draft so please excuse the various errors.
Code Reuse and the Burden of Interpretation
Experience shows that code re-use is not, in any useful sense, achievable.
It is interesting to note that code reuse per se is not the generic goal;
instead of focusing on reusing code it is more useful to think of solution
reuse where a solution can be thought of as either direct solution code or,
less obviously, as abstract solution code in the form of a problem
definition coupled to a code generator.
The current paradigm states that code and solution are one and the same
thing. This statement is false when humans are allowed to generate the code.
Humans will inevitably interpret the solution they implement as they
implement it. Hence their code represents their solution and must be infused
with personal interpretation. Thus each code component does not directly
equate to an absolute solution but is, instead, an abstracted, interpreted
isomorph whose detailed internal dependencies are to some degree unique to
the particular coder's design. All structured programming, naming
conventions etc are just so many attempts to agree on a general code
topology that allows the various isomorphs of a given solution (generated by
individual human coders) to be interchangeable. They fail because humans are
Interestingly this observation predicts that coders will tend to be loners.
An isolated individual is not subject to the effect described above for the
simple reason that isomorphs are relative. An isolated 'isomorph' is, in
fact, an internally consistent paradigm when viewed from the individual
coder's perspective. For an individual working alone the direct mapping
between code and solution is restored. Thus most coders ultimately prefer to
'do it their own way' if the solution space is small enough for individual
Leading on from this is realization that the problem with code reuse is not
one of technique but is instead a far more subtle and fundamental emergent
property of interacting human interpretations. Now it can be understood why
the only path to code reuse in a multi-coder environment is that of
restriction and convention because such rules result in an agreed, if highly
brittle, code topology whose specific function is to preclude an
individual's interpretation. Since humans must by definition make a priori
interpretations of anything they understand, then it can clearly be seen
that this approach is flawed at its root axiom; the very rules designed to
preclude interpretation are themselves subject to it before they can be
understood and applied.
From this it can be seen that code reuse would be greatly enhanced by
preventing the coder from applying their personal interpretation to a given
solution. If it is the case that the incompatible boundaries between
isomorphic solutions are indeed responsible for the lack of code reuse then
removing the coder will also remove inevitable variability of solution
interpretation and so enhance the prospects of reusing solution code.
The corollary to the observation that coders should not be involved with
solution code is that code reuse is only possible with code that has been
automatically generated by a consistent, non-interpretative framework.
Unfortunately this is not possible for the obvious reason that machines
cannot act as a prime mover, they cannot solve problems (even if they can
generate exquisite code solutions) because linear machines cannot define
problems without an initial, lateral input of a type currently available
only via a human intelligence. It is therefore impossible to eliminate human
interpretation from the ultimate solution code.
However the perfect should not be allowed to become the enemy of the good. A
fundamental revision of the coder's place in the process of solution
generation with the purpose of reducing the interpretation pollution they
engender is a worthy goal and should bring with it an increase in the reuse
of code. Put simply, the coder's task should be shifted from defining the
solution to defining the problem. Problem definitions vary far less then
their corresponding, isomorphic solution-sets and therefore problem
definitions hold out the possibility of being amenable to rigorous control.
Of course problem definitions must be subject to the same forces of
individual human interpretation but it seems likely that the interpretation
burden will be less. The notion of code reuse would also undergo a dramatic
revision with all attempts at solution-isomorph reuse being subsumed by the
reuse of problem-definition code.
To enable such a paradigm shift, a consistent yet generic code/solution
generator that consumes well-formed problem definitions is required.
Evolutionary programming provides such a system. The iterative logic of
selection provides the generic and consistent framework and the fitness
tests they consume are nothing more than definitions of the problem to be
solved. What is missing is the rigorous and consistent syntax for the coding
of fitness tests i.e. problem definitions. Should such a language become
available then it may be a simple matter for coders to make the required
shift from defining solutions to defining problems.
In summary it can be seen that likelihood of code reuse varies inversely
with the level of solution interpretation. Solution interpretation can be
greatly reduced by allowing machines to generate consistent code. Machines
can do this only if they are provided with problem definitions. Only humans
can generate the required primary problem definitions and so interpretation
cannot be eliminated entirely. The observation of greatest importance is
that the coder must shift from being a solution provider to a problem provid
er. The code that would be re-used would be the problem definitions.
Evolutionary programming appears to provide both the consistent solution
generation mechanism as well as a suitable problem definition framework.
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL