Posted by Jerry Stuckle on 10/07/07 19:15

Ben C wrote:
> On 2007-10-07, Jerry Stuckle <jstucklex@attglobal.net> wrote:
>> Ben C wrote:
> [...]
>>> I can believe you in theory, but I've never actually seen any good OO
>>> programming, and lot of bad OO programming. Where does this training
>>> come from? Who has this experience?
>> For one thing, I've been doing OO design for around 20 years, 17 of
>> those as a consultant. I've been on some projects which have good
>> designs, and managed OO projects. Also, I've taught several OOAD
>> courses to various organizations.
>>
>> The experience is in some corporations. I have been brought in as a
>> consultant when they don't have that experience, to help them along.
>> Some I train, some already have been trained but no experience.
>>
>> You're not going to get it out of a library book. This is something you
>> need to do hands on, with experienced designers.
>
> No disrespect, but this kind of talk isn't winning me over.
>

I'm not trying to win you over. I'm stating the facts. You can't learn
to play golf from a book, either. And you can't learn it by watching
videos of Tiger Woods and Arnold Palmer. You need to get out and do it.
And to do it right, you need classes and private tutoring.

> [...]
>>>>> OO can encourage people to make too many design decisions up-front,
>>>>> before they really know what they want to do yet.
>>>>>
>>>> Good design (not just OO) dictates that your decisions MUST be made up
>>>> front.
>>> For houses, yes, not for programs.
>>>
>> Nope, the same it true for programs. Otherwise those programs become a
>> mess of fixes, half-assed patches and other such stuff.
>
> Not true.
>

Wrong answer. I've seen it too many time.

The other option is to waste a lot of time completely rewriting code
from scratch.


>> It wastes programmers time and makes the code less reliable and harder
>> to maintain and modify later.
>
> No-one's arguing for spaghetti here. Everyone wants a well-structured
> program at the end that does the right thing and is easy to maintain.
> But how do you get there?
>

A proper design. Either structured or OO work will. But the design is
all important.

> There are no easy answers. OO and design up-front have plenty of
> problems too. The most obvious is committing to the wrong design too
> early because at the time of making the design the problem was not
> properly understood (however much everyone may have claimed they
> understood it).
>

A good design resolves most problems. And you are *much less* committed
to a design that's on paper than you are if you're written thousands of
lines of code.

But that is also part of project management. Ensuring the problem is
properly understood by all parties. And all parties agree to it.

It's a practice I learned over 20 years ago while working for IBM. And
it works.

>>>> Can you imagine creating the blueprints after the house is 1/2 built?
>>>> But that's how a lot of people approach programming problems.
>>> Indeed, and many programming problems are better approached that way.
>>>
>> Nope. No programming problem is "better" approached that way. Only
>> those who are either unable or don't want to plan ahead think that.
>
> In my experience many people believe they are more able to plan ahead
> than they actually are. Especially when they are put under pressure to
> produce professional-looking designs and plans.
>

And my experience is people believe they can write code even though they
don't understand the problem.

They can. But they're not writing productive code.

>> Programmers want to write code. You have to drag them kicking and
>> screaming to write *any* doc. And they will find every excuse they can
>> to not do it. Including that it "isn't necessary".
>
> Generalizations like that aren't helpful. If you insist on a doc, or a
> design, or a plan, then most people will produce them in order to make
> you shut up. They won't necessarily be any use though.

Yes, I insist on a design. And I use that design.

You've obviously never been on a project with > 100 programmers for over
two years. Or even one with a 3-4 programmers for six months to a year.

There is a formal process to managing projects, just like there is for a
lot of things. And it works. But when you've never used this process,
you can come up with all kinds of rationalizations as to why it won't work.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]