|
| Massively snipped - sometimes without notation - to avoid a ramble which
didn't work as this is majorly rambling. It's not intended for a response.
It's more that I agree with you in "principle" but am separated by a
differing view of what I call "realistic probability". Some people think
Marx was right and then some people think Wallerstein needed to make some
corrections to the theories to fit the real world when it become clear that
Marxism was flawed......I think your theories are right, but don't take into
account Fortune 500 companies and their goals. Crap analogy. Tis just food
for thought is more elegant.
Again, pleasantly surprised to your clc dedication ;-)
JCE
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3k4krvFsnis7U1@individual.net...
> "jce" <defaultuser@hotmail.com> wrote in message
<snip>
> Yes. see below.
> No, I would incorporate your functionality into a completely new function
> by adding methods and properties that do not HAVE to be used. The new
> function then includes the old one as a subset. I would NOT mess with the
> functionality that already existed in your component. (That's why source
> code is not such a big deal any more...)
You have duplicated the function unless your component stays logically
defined with the old component, or your component "hides" all the
uneccessary features of the first. You component is now out there and
supported by you whilst the old - supporting the same base function (that
you rely on) is no doubt supported by someone else.
From a purely aesthetic standpoint I do agree with you :-) I guess the
point I didn't make clear in my note is that I understand that you're not
tied to the source code, but you are tied to the new "source" code. For you
it's an API, for someone else it's an XMI and for others its still the old
source COBOL, C, Java.
I'm less worried about duplicate code, and more about management of
"worldwide interenterprise crossed with freelance and free source" functions
" where there are bucks to be made". _That_ - no one has sufficiently
addressed.
> That could certainly happen if you don't employ the constraints I have
> outlined above. The components are the property of the company and owned
> by everybody. You can see immediately, you don't want people amending the
> functionality. This fact will decide the 'granularity' of the components.
> Personally, I like fairly small building blocks and don't build massive
> functionality as a single component,
This works well in some instances, but software licencing is never that
easy. Someone may not _like_ your extensions of _their_ component. Someone
may _change_ their component in a way you don't like. I'm being kind of a
naysayer but business is business and when people don't have control their
are two things that can happen:
I don't want to play with you anymore, I'll make "better" friends.
I don't want to play with you anymore, and by the way it's my ball and I'm
taking it with me.
What happens is that you find different people with different balls - some
with a Gilbert some with an Adidas, some all weather, some real
leather...etc.
> It is also important to recognise elemental components and 'assemblies' or
> 'sub-assemblies' that incorporate them. Sometimes what are really
> assemblies are registered as components, and then confusion arises.
This is perhaps my hangup. Most useful offerings are 'assemblies' however,
so perhaps an easy "mistake?" to make
> Yes, but you are still looking at your tool as producing code for
> maintenance. I don't do that. I covered the fact that at some point the
> generator will include duplicated code; the difference is that it can be
> further processed to remove the duplication, if desired.
At some point someone will want to either (a) change something, or (b)
validate the perfect documentation.
In order to change something or validate something you need something in a
form that you can look at.
The maintenance I speak of is not "source" code, but the "new source". If
one built an App using MS Studio GUI, it would be soul destroying to know
that there is no way of "editing" or "validating" it.
> Nobody. That is my whole point.
I question the interface description - who validates it? Or more
importantly can figure out how to change it when validation fails.
I want to make an update, who and what do I use to update it?
I did slip and use the word "code" here which was unintentional - I meant
source. If it was as easy as this, then in my old source world, I would
never keep source, I'd create my object code and delete the program and be
happy that the compiler did its very best.
> The person building the system. Traditionally, a programmer, but it could
> be (and this is happening more and more) a knowledgeable business person,
> interacting with smart software.
Good luck finding a knowledgeable business person who has time to do this.
I'm finding that smart programmers are just moving up the business ladder
(often out of their depth too).
> Three tools touching code is almost as dangerous as one person
> At this point we diverge strongly. 'Good code' is simply a series of
> iterations, sequences, and selections, produced by standard algorithms,
> from something written by a programmer. The 'Good Code' can then be
> processed further. (Or not)
> In my scenario the whole purpose of refactoring is to acquire components
> for re-use. Source code maintenance is neither necessary nor desirable. In
> your scenario the refactoring is to 'straighten out' spaghetti and
> structure it, so it can be maintained. Source code is everything.
Again - a component cannot ever be a black box. You need to be able to
validate the documentation which is the "new source" which can arguably be
done with mere testing and boundary conditions. But should it ever fail ?
Then what.
Closed software is not the "in thing" - I'm not going to use a credit card
payment component without knowing that it's auditable.
I've used "code" again, but I mean source :-) I have no issue with a code
generation from a design doc or a nice tool - but I still want to be able to
understand the source. Anyone who used the Visualage visual editor can tell
you that it was great for creating code...was AWFUL for understanding it -
even the visual framework was not clear. So I never looked at the code it
generated, but the "source" the design palette _almost_ forced you to
abandon it and look at the code. If I had optimized it, then it would not
have worked in the visual framework and that's a problem to me.
> Both scenarios have their place. It's just that I, personally, have no
> interest in yours... :-). (I don't think it is 'wrong'; I just don't
> think it is a good reason to refactor code. To me, if you are hell bent on
> maintaining source code, rewrite the stuff from scratch.... It is
> certainly arguable... :-)).
Yes, but maintenenance is understanding and auditing. Someone +has+ to do
that. It's government mandated in my industry.
> That's like saying that supermarkets are useless because they don't
> actually put the stuff in your larder for you. :-)
Not really. It's like saying, I'm not paying someone to clean up my garage
if all they do is move stuff around without telling me where my junk is now.
> If that particular code works, exactly how is it's logic messed up? You
> are seeing only source code maintenance again. Assume for a minute it
> works, and you are never going to maintain it. Does it still matter if it
> is 'messed up'...?
If no one is maintaining it then what's the point of refactoring? If it's to
reuse the functionality in some other arena, then I would argue that you
+need+ to understand it. You could have code that has a rounding error
somewhere...then says "if error < $0.02 then display 'We're in balance and
skip this 2c'. Again, I'm +auditable+. The code does "work" - just not
very well. (And yes this is real and existed unknown to me until I fixed
the real rounding problem and someone noticed that the 2c file was always
empty )
> Procedural programming is obsessed with code maintenance, but it is
> actually the functionality that is important.
ALL programming is obsessed with code maintenance. Less than 10% of the
code I have ever written is "new" function. It's enhancements and
unfortunately "fixing".
> The prime evaluation criterion is that the program should work. Elegance
> of code is necessarily a lower priority than achieving correct
> functionality.
And then the priority immediately becomes ability to understand, fix AND
validate. I don't care if the fix is a code fix, or a gui fix, as long as
the "source" is readable and simple.
> Exactly. The need for such functionality was recognised. But you didn't
> not use it because you didn't have the source code, did you :-)?
The above was all availabe open source. Log4j is pretty slick and there is a
Log4p and a Log4c which will make you sick to your stomach :-)
Refactoring I have no questions that automation is faster, and accurately
reproduces what's there in a GIGO fashion.
[color=darkred]
> Prediction:
> As existing systems (particularly procedural coded ones, where source
> maintenance is a heavy requirement) are phased out, we are likely to see
> more code refactoring being employed. I don't believe it will be done with
> the object of straightening out the existing code, so it can be more
> easily maintained; rather, it will be done so that functionality can be
> encapsulated and embedded into new 'quick build' systems, and corporate
> packages like SAP and Siebel.
SAP/Siebel which allow Java and even better...their own proprietary
languages that keep people employed worldwide, whoopee :-)...how many ABAP
people we got in here?
> The Age of Source Code is almost over; the Age of Functionality is
> dawning.
I don't see them as separate things. Different forms of source code is
STILL source code - taken to an extreme the component you encapsulate is
still the source, it's just now that to validate I have to understand the
documentation of that component as by law in any US business where there is
ANY finances involved you are +mandated+ to understand it and be
auditable...the CEO's sign off on it.
JCE
|
|