Re: Just say no to threads [Was: Software architecture]
From: Vladimir Levin (vladimir_levin_at_yahoo.ca)
Date: 10/31/04
- Next message: Ilja Preuß: "Re: Strategy pattern and "related classes""
- Previous message: Phlip: "Re: Just say no to threads [Was: Software architecture]"
- In reply to: Debbie Craft: "Re: Just say no to threads [Was: Software architecture]"
- Next in thread: John Roth: "Re: Just say no to threads [Was: Software architecture]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Oct 2004 22:56:44 -0700
I was responding to the following statements you made:
>you say code is so easyto change, yet somehow i can't manage to code
something
>i have done before and that i know works? Contradictory and not
rational
and
>If you have done databases before it's no big deal. There is little
risk.
If you have done something before and you know it works, then reuse
it:
It must be a framework. If you need to write the code from scratch,
then
no, you cannot make the assumption that everything will go well. As
for database development, many books have been written on the subject
and many projects have been known to fail. Unless you are referring to
a toy application, such as storing a CD collection in Microsoft
Access, database development is a difficult subject.
It's clear that the larger the project, the more attention will have
to
be paid to large scale architectural issues. However, in the general
case,
it is best to leave the architecture as open as possible for as long
as possible. I believe that is what Phlip is advocating in his posts
in this thread, and my experience suggests it is a valid approach. For
example, our project team recently wrote a fairly sophisticated server
application in Java. During the development, it became clear that
standard Java I/O was not adequate, so the architecture was refactored
to incorporate java's "nio" or new I/O framework. How and where to
implement this was not evident from the start, and should not have
been decided in advance. Of course in the future, we will keep around
our knowledge of the limitations of the classic I/O api from Sun and
will act accordingly. Still, when developing a new, sophisticated
piece of software, one must tread lightly and advance design and
architecture iteratively. When developing an enterprise application, I
believe it is (or should be) a best practice to develop a lightweight
framework and iterate on that rather than to start off by
incorporating heavy duty frameworks right away, even if you are quite
certain you will be using those very frameworks.
Debbie Craft <d145@yahoo.com> wrote in message news:<10o7lhp2fnbsf30@news.supernews.com>...
> Vladimir Levin wrote:
> > I have worked with some very gifted programmers, if I say so myself. I have
> > seen these people continue to make errors even in scenarios where they
> > had written that same kind of code many times before.
>
> For getting code to work right we have TDD. That it is a different
> level then making decisions on what to do. You are saying
> something like if i speed that failure means i can't plan a route to the
> grocery before i start driving.
- Next message: Ilja Preuß: "Re: Strategy pattern and "related classes""
- Previous message: Phlip: "Re: Just say no to threads [Was: Software architecture]"
- In reply to: Debbie Craft: "Re: Just say no to threads [Was: Software architecture]"
- Next in thread: John Roth: "Re: Just say no to threads [Was: Software architecture]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|