Code reuse (was: Portability [OT])

SDL Development
#1

He also refers to “plan to throw one (a design or an implementation)
away”,

which means forget about that prototype, start over and make it better
this

time. This (lack of versionning) seems to be a pretty big obstacle and
that’s understandable: who wants to admit that the previous version
wasn’t

so great?
Well, once you’ve really tried throwing a few thousand lines away and
rewrite it all from scratch, I don’t think it will be that hard. It’s
incredible how superior each new version is to the previous one - and that
saves lots of time and frustration later on, when building on the code.

Design isn’t all about code, it’s also about data structures. If I may
paraphrase ESR again, smart data structures and dumb code is a lot easier
than the other way around. Sure, updating data structures (for a new
design) will mean updating/replacing a lot of code, but if the data
structures are smart, then the code will be easy [relatively speaking] to
replace anyway.

Especially in the proprietary world, where you have little time to clean
up
and rewrite code, you’ll be forced to add many times as many features as
you
could possibly imagine when designing the code. That’s when you wish you
spent a few more hours thinking that design through…

I think this applies to the situation you are describing:

“When you hit a wall in development – when you find yourself hard put
to think past the next patch – it’s often time to ask not whether
you’ve got the right answer, but whether you’re asking the right
question. Perhaps the problem needs to be reframed.”

A redesign is often a good idea in this situation, especially since the
non-techies that fund/control most software projects don’t always understand
why it is necessary to do so when all they want is this new feature.–

Olivier A. Dagenais - Software Architect and Developer

#2

He also refers to "plan to throw one (a design or an implementation)

away",

which means forget about that prototype, start over and make it better

this

time. This (lack of versionning) seems to be a pretty big obstacle and
that’s understandable: who wants to admit that the previous version

wasn’t

so great?

Well, once you’ve really tried throwing a few thousand lines away and
rewrite it all from scratch, I don’t think it will be that hard. It’s
incredible how superior each new version is to the previous one - and
that saves lots of time and frustration later on, when building on the
code.

Design isn’t all about code, it’s also about data structures.

By “code” I mean all source code of the project, including structure
definitions - and indeed, those are what really matters. The code that
manipulates the data can often be reused with some cut’n’paste without
causing too much mess, but the same is rarely true for data structures.

If I may
paraphrase ESR again, smart data structures and dumb code is a lot easier
than the other way around. Sure, updating data structures (for a new
design) will mean updating/replacing a lot of code, but if the data
structures are smart, then the code will be easy [relatively speaking] to
replace anyway.

Especially in the proprietary world, where you have little time to clean
up and rewrite code, you’ll be forced to add many times as many features
as you
could possibly imagine when designing the code. That’s when you wish you
spent a few more hours thinking that design through…

I think this applies to the situation you are describing:

“When you hit a wall in development – when you find yourself hard put
to think past the next patch – it’s often time to ask not whether
you’ve got the right answer, but whether you’re asking the right
question. Perhaps the problem needs to be reframed.”

Yep. :slight_smile:

And the problem is that “rewriting something that almost works” sounds like
an incredibly brutal and wasteful solution to non-programmers, so you usually
end up being forced to punch in another cludge - until the code is
essentially FUBAR, and you have to rewrite it at any cost, whether the
timing is good or bad.

Note: Serious software companies have the development and maintenance
departments entirely separated to reduce the risk of this happening.

A redesign is often a good idea in this situation, especially since the
non-techies that fund/control most software projects don’t always
understand why it is necessary to do so when all they want is this new
feature.

“Features” have to be built on top of something - one would think that’s
rather logical, but I guess it’s just that everything you don’t understand
anything about looks a great deal simpler than it is.

Non-programmers are usually not even on the level of understanding that
programming is not about telling a computer to just do something, but how
to do it. Even a functional language would seem scaringly explicit to them, I
guess… :wink:

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 22 February 2001 01:45, Olivier Dagenais wrote:

#3

Can you guys take this and the language discussions off-list? Thanks.

m.–
@Michael_Vance
http://linuxgames.com/michael/

----- Original Message -----
From: david.olofson@reologica.se (David Olofson)
To:
Sent: Wednesday, February 21, 2001 5:47 PM
Subject: Re: [SDL] Re: Code reuse (was: Portability [OT])

On Thursday 22 February 2001 01:45, Olivier Dagenais wrote:

He also refers to "plan to throw one (a design or an implementation)

away",

which means forget about that prototype, start over and make it better

this

time. This (lack of versionning) seems to be a pretty big obstacle
and

that’s understandable: who wants to admit that the previous version

wasn’t

so great?

Well, once you’ve really tried throwing a few thousand lines away and
rewrite it all from scratch, I don’t think it will be that hard. It’s
incredible how superior each new version is to the previous one - and
that saves lots of time and frustration later on, when building on the
code.

Design isn’t all about code, it’s also about data structures.

By “code” I mean all source code of the project, including structure
definitions - and indeed, those are what really matters. The code that
manipulates the data can often be reused with some cut’n’paste without
causing too much mess, but the same is rarely true for data structures.

If I may
paraphrase ESR again, smart data structures and dumb code is a lot easier
than the other way around. Sure, updating data structures (for a new
design) will mean updating/replacing a lot of code, but if the data
structures are smart, then the code will be easy [relatively speaking] to
replace anyway.

Especially in the proprietary world, where you have little time to clean
up and rewrite code, you’ll be forced to add many times as many features
as you
could possibly imagine when designing the code. That’s when you wish you
spent a few more hours thinking that design through…

I think this applies to the situation you are describing:

“When you hit a wall in development – when you find yourself hard put
to think past the next patch – it’s often time to ask not whether
you’ve got the right answer, but whether you’re asking the right
question. Perhaps the problem needs to be reframed.”

Yep. :slight_smile:

And the problem is that “rewriting something that almost works” sounds
like
an incredibly brutal and wasteful solution to non-programmers, so you
usually
end up being forced to punch in another cludge - until the code is
essentially FUBAR, and you have to rewrite it at any cost, whether the
timing is good or bad.

Note: Serious software companies have the development and maintenance
departments entirely separated to reduce the risk of this happening.

A redesign is often a good idea in this situation, especially since the
non-techies that fund/control most software projects don’t always
understand why it is necessary to do so when all they want is this new
feature.

“Features” have to be built on top of something - one would think that’s
rather logical, but I guess it’s just that everything you don’t understand
anything about looks a great deal simpler than it is.

Non-programmers are usually not even on the level of understanding that
programming is not about telling a computer to just do something, but how
to do it. Even a functional language would seem scaringly explicit to them,
I
guess… :wink:

file://David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’