|
|
Posted by Jerry Stuckle on 10/07/07 22:16
SpaceGirl wrote:
> Jerry Stuckle wrote:
>> 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.
>>
>>
>
> This is all very nice, but what about RAD? Or Agile? And how does this
> apply to small enclosed languages like AS3.
>
>
RAD proceeds even faster with a good design. You don't waste your time
on trial and error. And even with RAD tools, it takes less time to
develop the design than the code.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|