|
|
Posted by SpaceGirl on 10/07/07 21:19
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.
--
x theSpaceGirl (miranda)
# lead designer @ http://www.dhnewmedia.com #
# remove NO SPAM to email, or use form on website #
# this post (c) Miranda Thomas 2006
# explicitly no permission given to Forum4Designers
# to duplicate this post.
[Back to original message]
|