| Author |
Message |
Alan Balmer
Guest
|
 Posted:
Fri Oct 14, 2005 9:19 pm Post subject:
Re: Design first or Implementation first??? |
|
|
On Thu, 13 Oct 2005 20:30:43 -0400, Bill Todd <billtodd@metrocast.net>
wrote:
| Quote: | I still say: working with physical materials is fundamentally
different from writing code in a programming language.
Right. After all, it's not as if both involved creating fairly coherent
wholes that satisfied some real-world need, or using tools (with greater
or lesser degrees of expertise at doing so), or creating high-level
internal structures with significant inter-dependencies (some necessary,
some perhaps better avoided if possible to avoid unnecessary
interactions), or the use of sub-structures which themselves have
internal dependencies which may be amenable to patch-style fixes or may
require complete tear-down and rework in different situations.
You've described the intersection. Now take a look at the complement |
of the intersection..
--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net |
|
| Back to top |
|
 |
Alan Balmer
Guest
|
| Posted:
Fri Oct 14, 2005 9:23 pm Post subject:
Re: Design first or Implementation first??? |
|
|
On Fri, 14 Oct 2005 08:04:05 +0200, Terje Mathisen
<terje.mathisen@hda.hydro.com> wrote:
| Quote: | Scott Moore wrote:
Alan Balmer wrote On 10/13/05 10:11,:
Remember Knuth's algorithm for writing algorithms. The last step is
something like "Now you know how to do it, tear it up and start over
again."
Actually he said (in the "art of programming") that programmers should not
be afraid to rewrite code that had become unmaintainable, or needed to
be moved to a different langauge, since it would usually greatly improve
the code.
In my personal experience, any code that I really care about, I always
write it at least partly on paper first, often many different versions,
before I throw away the paper and rewrite it on the computer.
I guess this would be according to Alan's interpretation of Knuth. :-)
Nuts. I was going to look up the exact quote last night, and forgot. |
It's in TAOCP vol. 1, I'm pretty sure.
--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net |
|
| Back to top |
|
|
Bill Todd
Guest
|
| Posted:
Sat Oct 15, 2005 12:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
Alan Balmer wrote:
| Quote: | On Thu, 13 Oct 2005 20:30:43 -0400, Bill Todd <billtodd@metrocast.net
wrote:
I still say: working with physical materials is fundamentally
different from writing code in a programming language.
Right. After all, it's not as if both involved creating fairly coherent
wholes that satisfied some real-world need, or using tools (with greater
or lesser degrees of expertise at doing so), or creating high-level
internal structures with significant inter-dependencies (some necessary,
some perhaps better avoided if possible to avoid unnecessary
interactions), or the use of sub-structures which themselves have
internal dependencies which may be amenable to patch-style fixes or may
require complete tear-down and rework in different situations.
You've described the intersection.
|
No: I've described the *fundamentals*, which was the issue under
discussion - specifically here (see quote above), and more generally as
related to the relevance and nature of design. The differences are
primarily in the details, such as materials and specific physical
requirements on the implementor.
- bill |
|
| Back to top |
|
|
moi
Guest
|
| Posted:
Sat Oct 15, 2005 12:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
Alan Balmer wrote:
| Quote: | On Fri, 14 Oct 2005 08:04:05 +0200, Terje Mathisen
terje.mathisen@hda.hydro.com> wrote:
Scott Moore wrote:
Alan Balmer wrote On 10/13/05 10:11,:
Remember Knuth's algorithm for writing algorithms. The last step is
something like "Now you know how to do it, tear it up and start over
again."
Actually he said (in the "art of programming") that programmers should not
be afraid to rewrite code that had become unmaintainable, or needed to
be moved to a different langauge, since it would usually greatly improve
the code.
In my personal experience, any code that I really care about, I always
write it at least partly on paper first, often many different versions,
before I throw away the paper and rewrite it on the computer.
I guess this would be according to Alan's interpretation of Knuth. :-)
Nuts. I was going to look up the exact quote last night, and forgot.
It's in TAOCP vol. 1, I'm pretty sure.
|
And the three men I admire most:
They caught the last train for the cost
....
;-)
AvK |
|
| Back to top |
|
|
Guest
|
| Posted:
Sat Oct 15, 2005 9:45 pm Post subject:
Re: Design first or Implementation first??? |
|
|
Terje Mathisen wrote:
| Quote: |
In my personal experience, any code that I really care about, I always
write it at least partly on paper first, often many different versions,
before I throw away the paper and rewrite it on the computer.
I guess this would be according to Alan's interpretation of Knuth. :-)
|
I do lot of ground work before taking any hard step of implementing
things.. thats always right way of achieving target... Tell me how can
one implement something without knowing what exactly is he heading
towards...
I'm afraid... it would lead to some devastating code..
It wud sound rather like this....
if(design) return;
startCoding();
| Quote: | Terje
--
- <Terje.Mathisen@hda.hydro.com
"almost all programming can be viewed as an exercise in caching" |
|
|
| Back to top |
|
|
Maxim S. Shatskih
Guest
|
| Posted:
Wed Oct 19, 2005 12:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
Design for sure. Otherwise, you will end with a messy code and the need to
rewrite a lot from scratch at some moment (like Linux people did).
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
<embd_man@hotmail.com> wrote in message
news:1129394736.243287.241490@g43g2000cwa.googlegroups.com...
| Quote: | Terje Mathisen wrote:
In my personal experience, any code that I really care about, I always
write it at least partly on paper first, often many different versions,
before I throw away the paper and rewrite it on the computer.
I guess this would be according to Alan's interpretation of Knuth. :-)
I do lot of ground work before taking any hard step of implementing
things.. thats always right way of achieving target... Tell me how can
one implement something without knowing what exactly is he heading
towards...
I'm afraid... it would lead to some devastating code..
It wud sound rather like this....
if(design) return;
startCoding();
Terje
--
- <Terje.Mathisen@hda.hydro.com
"almost all programming can be viewed as an exercise in caching"
|
|
|
| Back to top |
|
|
Eli Gottlieb
Guest
|
| Posted:
Wed Oct 19, 2005 7:11 am Post subject:
Re: Design first or Implementation first??? |
|
|
Maxim S. Shatskih wrote:
| Quote: | Design for sure. Otherwise, you will end with a messy code and the need to
rewrite a lot from scratch at some moment (like Linux people did).
We already have one Windows v. Linux holy war going on, let's not start |
another one. Personally, I wouldn't give Windows an advantage just
because they <i>finally</i> switched to the clearer NT codebase about
5-6 years ago. |
|
| Back to top |
|
|
Brendan
Guest
|
| Posted:
Wed Oct 19, 2005 8:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
Hi,
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:dj3qls$2bel$1@gavrilo.mtu.ru...
| Quote: | Design for sure. Otherwise, you will end with a messy code and the
need to
rewrite a lot from scratch at some moment (like Linux people did).
|
I'm not convinced that messy code and rewrites are avoidable in
practice, at least not without enough prior experience.
In essence, you can't do a good design without knowing the implementation
details that experience brings, and you can't do a good implementation
without a good design.
My solution to this is to do a bad implementation to get experience that can
be used to do a good design, and then use that design for a good
implementation.
I'd also recommend splitting things into small independant chunks, so that
if (when) rewriting becomes necessary you'd only be rewriting a small
chunk rather than the entire thing (although for this to work you must have
a good design, with extra attention on the interfaces between chunks).
Doing heaps of research, and having goals that you are prepared to stick
with until you die of old age may also help.
Cheers,
Brendan |
|
| Back to top |
|
|
Alexei A. Frounze
Guest
|
| Posted:
Wed Oct 19, 2005 8:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
"Brendan" <NOSPAMbtrotter@gmail.comNOSPAM> сообщил/сообщила в новостях
следующее: news:aZk5f.22055$U51.13748@news-server.bigpond.net.au...
| Quote: | Hi,
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:dj3qls$2bel$1@gavrilo.mtu.ru...
Design for sure. Otherwise, you will end with a messy code and the
need to
rewrite a lot from scratch at some moment (like Linux people did).
I'm not convinced that messy code and rewrites are avoidable in
practice, at least not without enough prior experience.
In essence, you can't do a good design without knowing the implementation
details that experience brings, and you can't do a good implementation
without a good design.
My solution to this is to do a bad implementation to get experience that
can
be used to do a good design, and then use that design for a good
implementation.
I'd also recommend splitting things into small independant chunks, so that
if (when) rewriting becomes necessary you'd only be rewriting a small
chunk rather than the entire thing (although for this to work you must
have
a good design, with extra attention on the interfaces between chunks).
|
I agree on that. Good designs evolve over time and with experience. To be
able to generalize and abstract in order to get some good API and
implementation behind it, one first needs to do some real dirty work, write
lots of bad code, learn from there, learn from particular details how things
work in particular and only then it's possible to draw lines between
components of the system, to define generic and specific features and
functionality, etc etc. The truth is that none is born with the knowledge of
the things neither in general nor in particular. How we learn is dictated by
the nature of what we are -- and we learn from concrete simple things first
and then progress towards more and more complex and abstract. It's
inevitable. We get our thinking noticably changed by the age of 12 or
something, when we've gained quite a lot of simple and concrete experience
and are mature enough to do basic logical reasoning and deal with
abstractions. Similarly to this part common to all our lives, we also do
specific studies and training in the areas of our interest and profession.
And there too we start from little and often clumsy steps, it's just how
things are...
Alex |
|
| Back to top |
|
|
Maxim S. Shatskih
Guest
|
| Posted:
Wed Oct 19, 2005 4:15 pm Post subject:
Re: Design first or Implementation first??? |
|
|
| Quote: | In essence, you can't do a good design without knowing the implementation
details that experience brings, and you can't do a good implementation
without a good design.
|
You can do the more-or-less-OK implementation without the good design, but at
some moment it will become a support nightmare, and you will need to rewrite
large pieces from scratch.
| Quote: | I'd also recommend splitting things into small independant chunks,
|
The most popular design principle. Called "encapsulation".
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Maxim S. Shatskih
Guest
|
| Posted:
Wed Oct 19, 2005 4:15 pm Post subject:
Re: Design first or Implementation first??? |
|
|
| Quote: | work in particular and only then it's possible to draw lines between
components of the system, to define generic and specific features and
functionality, etc etc. The truth is that none is born with the knowledge of
|
But note the danger: overdesign (too large bias to abstract things) can cause
problems too. Worse performance (if performance is sacrificed for a sake of
better-looking abstraction), the necessity to write more code just to satisfy
the abstraction, and so on.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Eli Gottlieb
Guest
|
| Posted:
Wed Oct 19, 2005 4:15 pm Post subject:
Re: Design first or Implementation first??? |
|
|
Maxim S. Shatskih wrote:
| Quote: | In essence, you can't do a good design without knowing the implementation
details that experience brings, and you can't do a good implementation
without a good design.
You can do the more-or-less-OK implementation without the good design, but at
some moment it will become a support nightmare, and you will need to rewrite
large pieces from scratch.
I'd also recommend splitting things into small independant chunks,
The most popular design principle. Called "encapsulation".
Funny, I was under the impression the most popular design principle was |
"functionality", or did Java kill that one? |
|
| Back to top |
|
|
Jeremy Webber
Guest
|
| Posted:
Fri Oct 21, 2005 8:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
"Maxim S. Shatskih" <maxim@storagecraft.com> writes:
| Quote: | But note the danger: overdesign (too large bias to abstract things) can cause
problems too. Worse performance (if performance is sacrificed for a sake of
better-looking abstraction), the necessity to write more code just to satisfy
the abstraction, and so on.
|
I would recommend looking at some of the ideas of Extreme Programming (XP)
(google it) to assist. Other process models such as RUP will also
help.
In essence, I believe that the current preferred practise is iteritive
development, where you do a bit of design, then a bit of
implementation. Each iteration should be functionally complete,
though the first few iterations may not implement very many of the end
user requirements. Early iterations are used to refine requirements
for later iterations. Each iteration gives the end user something
they can try out.
This approach can be a good way of reducing risk of incorrect
requirements, which is the major risk in most software development
projects.
XP emphasises test before code, and never designing for more than
current requirements. I.e. design ONLY for the requirements of the
current iteration, not the eventual requirements, as they will change.
It also emphasises the need to be willing to "refactor" (essentially
redesign) during later iterations to account for changing
requirements.
There is, of course, a lot more to XP than just this.
-j
--
Jeremy Webber Senior System Administrator
Animal Logic
Phone: +61 2 9383 4837 Fax: +61 2 9383 4801 Switch: +61 2 9383 4800 |
|
| Back to top |
|
|
Maxim S. Shatskih
Guest
|
| Posted:
Fri Oct 21, 2005 1:46 pm Post subject:
Re: Design first or Implementation first??? |
|
|
| Quote: | XP emphasises test before code,
|
Overkill for most parts of the product. For UI, for instance. Necessary for
low-level "system" stuff.
| Quote: | and never designing for more than
current requirements. I.e. design ONLY for the requirements of the
current iteration,
|
Bad idea. Very, very bad. This can easily mean the complete rewrite of major
parts of code from version 1 to version 2.
Usually, the future requirements are more or less predictable, and are taken
into account in _design_ process of phase 1, but not in _implementation_
process. Like "we must design the system to be extendable in this direction in
the future, but we will not extend it for now - it's for later, just leave the
necessary plugs for the future extension here and there".
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
|
Phlip
Guest
|
| Posted:
Fri Oct 21, 2005 4:15 pm Post subject:
Re: Design first or Implementation first??? |
|
|
Maxim S. Shatskih wrote:
| Quote: | XP emphasises test before code,
Overkill for most parts of the product. For UI, for instance. Necessary
for
low-level "system" stuff.
|
First you say that tests are overkill, then you claim that changing code is
a very bad idea.
If you don't spend a few minutes writing tests, you will spend long hours
debugging. Folks who test first widely report almost never debugging.
So maybe the debugging is overkill. Implementing by debugging has higher
chances of making code hard to change than implementing by testing.
| Quote: | and never designing for more than
current requirements. I.e. design ONLY for the requirements of the
current iteration,
Bad idea. Very, very bad. This can easily mean the complete rewrite of
major
parts of code from version 1 to version 2.
|
If you got paid for Version 1, this increases the odds that Version 2 will
exist.
Next, if you test before designing, the tests will support the rewrite.
Next, if you refactor _during_ each iteration to keep the code as clean as
possible, it will be modular enough to support rewrites.
The hard rewrites I have seen came from
- code designed up-front, before tests
- speculative designs that emphasized the wrong flexibilities
- poor implementation without cleaning up long functions
- poor language selection (and its attendant culture)
So if you never set yourself up for a bad rewrite, you might find that large
changes of clean tested code are easy and kind of fun.
| Quote: | Usually, the future requirements are more or less predictable, and are
taken
into account in _design_ process of phase 1, but not in _implementation_
process. Like "we must design the system to be extendable in this
direction in
the future, but we will not extend it for now - it's for later, just leave
the
necessary plugs for the future extension here and there".
|
When you refactor to merge duplication, during this iteration, you
overwhelmingly replace that duplication with extendible abstractions.
Suppose your code says
if apples
makeAppleButter
else if pears
makePearJam
else if bananas
makeBananaPie
The cleanest way to squeeze out duplication is factor up a base class,
Fruit, and derive these classes from it. Then put the differing behaviors
inside the derived classes.
Maybe the next version will have a Strawberry class; maybe it won't.
XP says to do this regardless whether your requirements indicate you
actually need a Fruit class. So under XP the odds of a shift in requirements
causing a big rework in the design is very low.
Keeping code constantly clean, under test, makes these extensions and
changes very easy.
--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!! |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in