class properties in c++
David Demland
plug-devel@lists.PLUG.phoenix.az.us
Fri Jun 15 21:48:01 2001
I wish to make it clear that I did not mean to upset anyone. While I will
admit that I have been on a soapbox, I am not the only one. The fact is that
we need people on soapboxes just to call into question many things that may
be going on around us. There is nothing wrong with this. Through out our
history there has been many prophets and philosophers that have been looked
on as if they were on a soapbox. With that in mind I will say my peace and
let this go.
What has happen here is exactly why I have said we need to ensure we use the
same words for the same meaning. While it has been said that words like
functions and methods make a mediocre engineer this is not what the point
was. The point was that if the prevailing attitude is “we are human we make
mistakes big deal” this is what leads to mediocre engineering. Yes we do
make mistakes I understand that. But the biggest mistake occurs when accept
mistakes. When I came to CADTEL many of our programmers had this type of
attitude. To prove that this was not good I calculated that we were
averaging 130 bugs per thousand lines of code. I could not believe that we
produced this bad of code. I got on my soapbox, yes I get on it other places
as well, about how we can not accept errors of any kind. In three years our
bug rate dropped down to 50 bugs per thousand lines of code. Although this
is still not where we should be, we did improve.
Not only was it important for development to use consistent terms, but by
ensuring that everyone used the same terms we have seen an improvement with
our requirements. Studies show that over 40% of all projects fail because of
requirement related problems. By getting our development team to think
alike, we have been able to start to get our marketing team to think the
same way. We are now starting to get not only clear requirements from
marketing, but complete ones. We are now starting to deliver projects on
time. Finally we are moving from the 85% over time side to the 15% on time
side of the statistics. This has been our goal all along. It can be said
that we are a mediocre species - but mediocrity, just like striving for
perfection, is a choice. That ability to chose to change how we think about
things is what sets us aside from the rest of the animal kingdom.
I understand programming and OO very well. I also understand the development
process just as well. It is impossible for anyone to say they have the right
solution to any problem. If anyone finds this hard to accept then give a
definition of what is right. In any given problem correctness can only be
determined if the solution is evaluated in light of what the requirements
are. For any given project an engineer can develop a great solution for what
he perceives the problem was, but if that does not match what the customer
perceived the problem as then the solution is wrong. What I have observed in
this field is that there is no right answer to a problem but there is always
the possibility to have a wrong one. Many times it is hard to know the right
answer because the requirements are changing almost to the end of the
project if they are not controlled. These are the cases the a project will
never be close to right.
As far as the goal of OO in modeling the problem, let’s keep in mind that
everyone see the world a little differently. If this was not true there
would be no conflicts in what different people say happened as a witness to
an event or disaster. I am have never debated that any of my ideas were
perfect. I just gave an example of how I saw that something could work, it
was not meant to say it was the only way to work. If someone read that into
what I was saying than I am sorry. I have never believe that there is a
better way to do anything in this forum. Without the full picture, all the
requirements, no one can make that call. Even with all the requirements I am
not sure I would be able to say one option is better than another one. It
depends on how you look at the problem. Weather something is a problem or
not only the customer can say. But if the customer can not see the
difference then either way is right.
There was a time when we implemented something one way for the fastest
speed, but the user had a perception that is was slower even though the time
test showed different. Yet when we actually slowed down the code doing
something different, the user perceived that it was faster. Which way was
the right way to do it?
To make the statement that we should allow “real” programmers to do their
job would say that this is an art form open to the whims of the person
creating the art. When I have seen this I have not always been able to see
good code or a good product. For this reason I would contend that this is
not an art form. The other option would be that this is more of a science
that an art. But I am not sure I would call it a pure science either. If
this was a pure science, then some of the dreams of CASE creating working
systems without a software engineer would be true today. Would it be better
to call this a craft instead of either an art form or a science? I would
rather go this path because like any other craft the best craftsmen are the
ones who take both the art form and the science and meld it into something
that defy true definition of either.
Thank You,
David Demland
Qa/Process Manager
CADTEL Systems, Inc.
11201 N. Tatum Ste. 200
Phoenix, AZ 85028
(602) 648-6054
Fax: (602) 953-4833
ddemland@cadtel.com
-----Original Message-----
From: plug-devel-admin@lists.PLUG.phoenix.az.us
[mailto:plug-devel-admin@lists.PLUG.phoenix.az.us]On Behalf Of Rob
Wehrli
Sent: Friday, June 15, 2001 11:26 AM
To: plug-devel@lists.PLUG.phoenix.az.us
Subject: Re: class properties in c++
> I understand that for the mediocre engineer names mean nothing. But to
take
What planet are you from, man? You're saying that the "difference" between
"function" and "method" and "operation" *names* is some kind of metric for
determining what makes mediocre engineers?
> care of every aspect of you job is what separates the mediocre from the
Spoken like a true "QA" guy...my point is that we're not perfect. We, as a
species, are not so good at taking care of *every* aspect of "you" job. We
make mistakes. We're error prone. We are mediocre as a species because of
our errors and our methods that allow us to send them out even when we know
it. However, perfection is not our goal.
> great. Just like I tell some of the teaches I work with, if we are sloppy
in
> our words, and names, we are sloppy in our work. After all if the words,
and
OK. So you and some of the "teaches" you work with are sloppy in your work
because you pick your words less carefully than perfection dictates. Your
admission that you're mediocre comes as no surprise when the entire race is
basically in the same boat.
> names, are just slung around, how will any one doing maintenance on the
code
So, now you're back on, pointing the finger at anyone who calls a "method"
(your choice of terms) a "function" (their choice of terms) simply because
of some pseudo-religious belief you have regarding naming here? I'm perhaps
one of the stronger proponents of quality naming decision making and
conventional naming practices. If we assume that to be true and if we
assume that I have any skill at all in it, wouldn't I be just as "picky" as
you about calling a method a function? So what you're really saying is,
"Rob, you're a mediocre engineer because you are sloppily calling methods
functions." Hell, I call them operations, too. I guess that I should be
immediately excommunicated among C++ and OO programmers and relegated to a
life of writing spaghetti BASIC code the rest of my days.
> know what the intent was? After all this is the problem in maintenance,
> knowing what was indented so that the fix, or change, may be applied
> properly.
Huh? Knowing what was indented? Do you mean intended? Perhaps your word
choices here are a reflection of your "if we are sloppy in our word, and
names, we are sloppy in our work" in practice? Some kind of
"self-fulfilling" prophecy? By your own admission, we are sloppy because we
make errors. Wow. We better alert the media. NEWS FLASH HUMANS MAKE
ERRORS details at 6 and 10.
>
> After all as any Object Oriented engineer knows, there are many things
from
Which engineering discipline is a OOE? Is that electrical, mechanical,
civil, nuclear, chemical, biological...help me out here.
> structural engineering that do not fit the goal of OOE (Object Oriented
> Engineering). By the way, with many schools still teaching structural
> techniques, are you that certain that everyone knows what we are talking
> about?
Just because procedural programming (how did "engineering" get infused with
every kind of programming?) is still very common in many schools doesn't
mean that students are not familiar with OO concepts. I'm quite certain
that YOU don't have a clue about what I'm talking about. I recall that you
were the guy telling the PLUG devel world that a Dealer ISA Player. You
were pushing your crap design onto this group as if it was the world's best
thing. It must have had 100 "OOP holes" in it and now you're saying "we"
are mediocre because we are sloppy in making the *obvious* distinction
between function and method when you couldn't "explain" it in any reasonable
way? Get off your soapbox and get off of the notion that you've got some
kind of clue. I don't resent you for not knowing. It is natural to not
know something. I resent you for spewing forth here in this forum as if you
DO know, when all you have is a set of BS opinions and quite a bit of
*obvious* misinformation about what OO is really all about and you think
that you're too good for the rest of us who are just trying to learn and
share here.
Don't lump together simple sentences such as procedural programming doesn't
provide for the goals of OOP...especially by calling it "engineering."
Structural Engineering is akin to building bridges, skyscrapers and such,
structural programming is entirely different. Anyone who would mix *these
terms* is either trying to add "weight" to an argument or simply a very poor
user of terms. I think that you'd be very hard pressed to find your
proposed acronym "OOE" in any real place where OO is talked about...except
in such likely instances where it is just about ALWAYS accompanyied by
"Software," as in Object Oriented Software Engineering.
>
> I would like to say that I am not trying to put any one down. As a
manager,
> and a teacher, I always try to improve everyone I work with, or teach.
Maybe
Are you really a "teacher?" Whom do you teach? Maybe you should spend more
time and energy trying to improve yourself and make yourself competent
before "always" trying to improve others...especially in situations where
they're calling a method a function or some other relatively synonymous
term. If you were so blasted right about this, why don't you follow the
trend of OOADers and say Operation? I'm guessing that you'd like to ramble
on for hours about whether you prefer Booch to Jacobsen. I remember seeing
oh soooo many posts on the various OO usenet groups regarding your theories
and findings.
> I live in a dream world, but I live to see the day when the general public
Let me know when you finally wake up, because I, for one, am getting tired
of your "sharing" your dream world out loud.
> finds that software is reliable, dependable, and so useful they look
forward
> to using it. I can not stand hearing all the jokes about software, and
> software developers, producing crap, But after all the general public has
If you can not stand it, then quit offering it. What does it take for you
to just be one of the people searching for answers like the rest of us? Are
we supposed to blindly follow your spewing that Dealer ISA Player now? How
much thinking went into *that* design? Why not lecture me at length about
your reasons for using interfaces-based models for inter-object
communication? What do you see as the pros and cons in public, private and
protected members? Why not go in-depth about why you think that Dealer is a
specialization of Player? ...and why that would make such a good OO design?
> developed the attitude "hey this is not Burger King you can not have it
your
> way" and is this the right way to treat them? I can not see how anyone can
> be happy working in an industry that has the reputation for being a
> necessary evil we have to live with.
There are those of us who have to fight the battles every day that just
because the simplicity and proliferation of tools has made it easier for
non-programmers to write programs, we do care about the software we produce
because we're professionals and we do take our work seriously. That is not
to say that we do not make errors, in fact, we expect to make many of them
in the course of a development activity. What we do is design our programs
in such a way that they enable us to make errors and make changes in such a
way as to fix them so that we can move onward. I think that it is clear
that "we" will never mean "all." And, these days, it seems that we is
really a much smaller group than ever before...and that there are WAY TOO
MANY people who push their own little bent ideas at a "unsuspecting" group
of developing programmers because they are "teachers" and "managers" and
have some kind of way of talking as if they are right all the time.
>
> All I am trying to do is to show that by taking care of what we do, and
> being the best at it, we can produce great software every time and the
> consumer wins when this happens.
If that is all you're trying to do, then stick to QA and let "real"
programmers do the programming. Catch the errors you find, let the
programmers know about them so they can fix them and keep trying to learn
how to develop decent OO applications. Don't make the rest of us suffer
through your discovery process as if you already know all the answers and
are better than the rest of us because you're a "manager" and you're a
"teacher." What are you going to teach us next? Methods are not functions?
Just because you say it, it doesn't mean JACK. If you're going to go out on
that limb, then, damn it, you better have a half-way decent argument as to
why the rest of us should change. Either that, or KYFMS. Think about it.
All of this because you had to tell some guy that "methods, not functions.
I am right and you are wrong." Tell me this, if Herb Schildt, Andy Koenig
and Scott Meyers were sitting in the room and they said "then you call this
function," would you pipe up and tell them that it isn't a function, it is a
method? Of course, you could offer that they would never say such a thing;
but the last time I sat with Scott Meyers and gang and talked, I didn't
notice any distinct avoidance of "function" in their vocabularies. Also,
Stan Lippmann uses functions synonymously with method and operation in my
discussions with him. How about a random web site?
http://mason.gmu.edu/~herwin/debug.html where a CS 310 class professor named
Harry Erwin uses "function" quite a bit, too. Maybe your teaching skills
have surpassed his accomplishments, too. Maybe, like the rest of us, he's
just backwards.
>
> Thank You,
>
> David Demland
> Qa/Process Manager
> CADTEL Systems, Inc.
> 11201 N. Tatum Ste. 200
> Phoenix, AZ 85028
> (602) 648-6054
> Fax: (602) 953-4833
> ddemland@cadtel.com
PS. Sorry to be so "unkind" in this message. Sometimes you have to whack
the drunken bum "upside" the head with the empty Vodka bottle to let them
know that they're a drunken bum. Meanwhile, I think that none of us want to
"turn away" someone who really wants to be a "contributor" to this list. If
you want to play nice, I'll play nice, too. If you want to spew forth, take
it somewhere else. No one promoted me to BS Police Chief, but then again, I
too care about how "we" as programmers are received by the population of
users. I guess that if I'm ever looking for a job at CADTEL, I'd better not
use you as a reference, huh? You're not going to like me from now on
because I wouldn't play your little game of what you believe is true is true
for the rest of us too. Why not admit to yourself that you've only got half
a clue and work like the rest of us at finding the other half rather than
spending time and energy telling us that you already found it? I think that
once you come down off of your pedestal, the rest of us will be glad to help
you along the way. Now it is my turn to jump off of the BS Police pedestal
and get back in line with all the other searchers. Maybe go to a patterns
group meeting. Learn from some of the many good programmers around the
valley that there are some really good things to do when you start
"objectively" sharing. :)
Take Care.
Rob!
_______________________________________________
PLUG-devel mailing list - PLUG-devel@lists.PLUG.phoenix.az.us
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel