| Author |
Message |
Maxim S. Shatskih
Guest
|
 Posted:
Fri Oct 21, 2005 10:49 pm Post subject:
Re: Design first or Implementation first??? |
|
|
| Quote: | 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.
|
How will you test the UI in such a manner?
| Quote: | Next, if you test before designing, the tests will support the rewrite.
|
How? You will need to rewrite both the tests and the code itself.
| Quote: | The hard rewrites I have seen came from
- code designed up-front, before tests
|
How tests can help design? Tests are for testing/catching bugs, not for design.
| Quote: | - speculative designs that emphasized the wrong flexibilities
|
For me, this can cause a) overkill in man-hours and slipped schedule b)
performance issues, but hardly the rewrite issues.
| Quote: | - poor implementation without cleaning up long functions
|
Yes, this one maybe.
| Quote: | - poor language selection (and its attendant culture)
|
Yes. This can cause numerous issues.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com |
|
| Back to top |
|
 |
Scott Moore
Guest
|
| Posted:
Fri Oct 21, 2005 11:30 pm Post subject:
Re: Design first or Implementation first??? |
|
|
This is WAY overcrossposted by the way.
Maxim S. Shatskih wrote On 10/21/05 01:46,:
| Quote: | XP emphasises test before code,
Overkill for most parts of the product. For UI, for instance. Necessary for
low-level "system" stuff.
|
The idea is that good programmers will eventually test their code, so you might
as well write the tests first. To do so is actually LESS effort, because of the
simple reality of the way programmers work. They test ad-hoc while developing,
like running it and going "gee wiz" when it does or does not work. Then the
formal tests are designed after the thing is done. Having the tests written first
means that the ad-hoc work is done instead by the specific tests, and that
effort is not only not repeated, but done according to a plan, instead of
off the cuff.
| 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".
|
Depends. The enemy of finishing code is building wishful thinking into the
product, such as making a "really cool" installer while the product to be installed
is coming to market late. Most products are not unextendable because nobody
thought ahead, they are unextendable because they are poorly written. |
|
| Back to top |
|
|
Scott Moore
Guest
|
| Posted:
Fri Oct 21, 2005 11:37 pm Post subject:
Re: Design first or Implementation first??? |
|
|
Maxim S. Shatskih wrote On 10/21/05 10:49,:
| Quote: | 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.
How will you test the UI in such a manner?
|
By automating the inputs. There used to be programs designed to do
this, programs that passed (say) windows events into your program.
However, that is now something you do for yourself. I make EVERYTHING
automatable in a Windows app, either by interdicting the events input, or
by establishing a scripting language to drive it.
| Quote: |
Next, if you test before designing, the tests will support the rewrite.
How? You will need to rewrite both the tests and the code itself.
|
Yep. The test code, the program code, and even the documentation, evolves.
My flow is:
1. Document what it will do.
2. Design tests for that.
3. Program.
4. Redesign tests, code or even docs for bad assumptions and mistakes.
5. Repeat. |
|
| Back to top |
|
|
Alan Balmer
Guest
|
| Posted:
Sat Oct 22, 2005 12:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
On Fri, 21 Oct 2005 23:27:55 GMT, "Hank Oredson"
<horedson@earthlink.net> wrote:
| Quote: |
My 40+ years experience tell me that the above is incorrect.
It is a portion of what one must consider, but if you think
you can predict the "future requirements" then they are not
"future requirements" but "present constraints".
|
You don't need to know what the future requirements are in order to
write code which is amenable to change.
--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net |
|
| Back to top |
|
|
Hank Oredson
Guest
|
| Posted:
Sat Oct 22, 2005 12:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:dja9qj$2euk$1@gavrilo.mtu.ru...
| Quote: | XP emphasises test before code,
Overkill for most parts of the product. For UI, for instance. Necessary
for
low-level "system" stuff.
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".
|
My 40+ years experience tell me that the above is incorrect.
It is a portion of what one must consider, but if you think
you can predict the "future requirements" then they are not
"future requirements" but "present constraints".
--
... Hank
http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli |
|
| Back to top |
|
|
Shaun
Guest
|
| Posted:
Sun Oct 23, 2005 12:15 am Post subject:
Re: Design first or Implementation first??? |
|
|
Brendan 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.
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.
|
Couldn't agree more, I have often found that it is all too easy, if you
don't keep implementation details in mind, to gloss over the hard bits
during design. That way you can risk ending up with a beautiful design
that happens to be horribly or impossible difficult to implement.
Ultimately it does boil down to experience, and I find that even when I
am able to just start slinging out code, it is only because I have at
least thought ahead a few steps.
I think it takes experience to get a feel for what is good design while
you are doing it, and over time one can start doing less design on
paper and more in there head, but there is always some design before
implementation unless the problem is really trivial. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in