While posting to my thread on physician practice management software,
I decided to take some OT thoughts to a new thread. I warn you, this
might just be a ramble.

I am not particularly fond of code written by code generators unless
it comes from one of the currently maintained products, and even then
I don't usually like to have my hands tied by someone else's notion of
what I should be able to do in code or how I should do it. In the
back of my mind I'm fighting to avoid older products like Wizard,
Forge (sorry Chandru), or even SB+ paragraphs. I like ATGUI but only
if the business rules are truly divorced from the UI.

I'm trying to not lump all of the GUI/RAD/IDE products together in
this, including SB+, DesignBais, OSMOSiS, Nucleus, Visage, Simbion,
WebWizard, or even FlashCONNECT and Coyote which are toolkits with no
UI. These products facilitate development, and as long as some part
of the code written in these products is portable, I have no problem
with them. Each one, however does tie you in with product-specific
nuances and our decision to use them includes having some idea of how
long they'll be around. Product differentiation is of course
unavoidable, but I personally prefer products with a lighter footprint
(no so much product-specific code required in the app) to those, like
Coyote for example that essentially change the language and coding
paradigm to support a new UI. The question any developer has to ask
is "what is the benefit I derive now vs the pain some tool might cost
later?" In most cases, "later" isn't a consideration, and most
developers assume that as long as we're working with something we like
now it doesn't matter who gets stuck with it later. And then there is
the idea, as with Coyote for example, that the product actually does
have longevity and there will always be someone around to maintain app
code written around it, so who cares how it ties into the app?

What I really don't enjoy is getting a call from an end-user who needs
assistance and after discussion of all the great things we can do with
their MV system I find out their code is written with some commercial
or home-grown tool that isn't maintained anymore. So now the options
are to contract with someone else who has skills with the old code, to
manually rework the generated code, or to re-write. We pride
ourselves on working with a platform that is easy to maintain but then
we stick end-users with unmaintainable code. Often their only
recourse is to migrate. My business solution to this to focus on
mainstream products rather than picking up orphans. There are plenty
of people who enjoy the diversity of working with these orphan sites,
learning the code and becomming the new IT resource.

When writing code, I'm particularly careful these days to try and
separate UI from rules, so that the rules can be used by any UI or
development tools that come along. This development style is a
choice, not absolutely required, and honestly there are few Pick shops
that will pay for the extra time required to implement this, so the
reality is that a lot of end-user code I write has some measure of
rules mixed with the UI code. Same goes for code that abstracts data
access and data structures from the rules. Good design and forward
thinking are nice ideals, but very few companies will pay for it.

Maybe this is further OT but it's interesting that no one in our
market writes material like "Design Patterns for MV" - of course I'm
sure few people would buy material like that too, unlike in the
mainstream world where this is a very important topic. I'm wondering
how other people deal with the concepts above and if we can derive any
best practices from the various coding techniques and business
decisions that relate to them.

Thanks and Regards,
T

On Tue, 09 Aug 2005 15:48:32 -0700, Tony Gravagno
<g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote:

There's no such thing as a split model in this market simply because
no one wants to maintain a UI and a logic model on separate levels.
The skill here is in dataBASIC and that's where everyone wants full
control. That ideology is changing, but I feel it's taking way too
long to keep up with the rest of the DB world.


That's where OSS comes in handy. OSS source code will always be
available for maintenance and enhancement. If the open source
development is centralized and kept updated, then there's no
end-of-life for it. There are always things to consider when looking
at OSS code for commercial development, including the license the code
is released under. I think that, above all things, is the brick wall
that make so many commercial developers wince and therefore shy from
OSS integration. Well, you can't have an immortal product without
opening it up for the public to maintain it. Opening up an interface
module for your app is a small price to pay for a product that you
know will always be around for enhancement and possibly redesign.

That depends on how you present it. That typical lack of forward
thinking is the reason we're in so many predicaments to start with.
Being the lone IT 'expert' for a private company, I see this argument
from both sides. When you're running a business on low margins, you
don't want bells and whistles. Most companies aren't going to pay for
future expansion possibilities, especially if growth and technology
can not be projected far enough in the future to perform an ROI.

The survey from PickSource a few years ago showed that a good (80% +
I think) percentage of developers and VARs would be willing to
participate in a developer's guild or organization. I have way too
many external projects right now to even consider starting such a
thing, but I honestly believe that developers are hungry for info and
ideas to help them make design decisions. If a couple of commercial
figures could be convinced in funding such an organization, then we'd
be one step closer to bringing the MV world together. Right now,
there's still way too much seperation between flavor audiences. The
only way it's gonna happen full-tilt is to bring in logos to show
commerical support from all the major players.

Glen
http://picksource.com
http://mvdevcentral.com

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

I'm guilty as changed. I'm one of those non-technical business types who
learned how to write Pick code and wrote an entire application with no
concept of software design. That was 15 years ago. I'd like to start over
and do it right, but with over 1,500 programs and 250,000 lines of code,
that is virtually impossible.

We are now in the process of putting a gui front end on the software, but
the back end remains the same. We are trying to do it right, maintain
flexibility, and anticipate future situations. Eventually the business rules
and UI may be separate.

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

G'day Tony,

Drawing a few of your thoughts together (in my mind at least), part of
the reason you don't see "Design Patterns for MV" may be because
the 'patterns' are implicitly part of the structure imposed by the
IDE/GUI/RAD tools you mention? Even the 'home grown' tools probably
grew from a basic understanding and implementation of patterns.

Your comment that you don't "like to have my hands tied by someone
else's notion of
what I should be able to do in code or how I should do it" indicates
that either the pattern is no longer valid, or perhaps the
implementation is different than the way that you would have done it
(which doesn't necessarily invalidate it) - of course it may also
be that the tools that were used WERE 'sub-optimal', or are simply
'dated' because they haven't been updated in 15+ years (which is
probably more likely I'd guess !?)

(I must admit that on my first run through I thought that this
statement (tied hands) was contrary to the desire to see patterns, but
I think the confusion was in my initial interpretation - the
"joys" of English/American/Australian/Computer Science language &
terminology)

I also have to point out that the decision to 'rewrite or replace'
is not limited to mv software - I've seen applications written in
Java be replaced with a .NET development strategy, or a VB application
re-developed in Java. - and NONE of the code (before OR after) was
necessarily "maintainable" except by the original development team
members

You shouldn't necessarily discount the rewrite option so quickly -
if there is a sound business case for adding that whiz-bang new
feature, then this could easily be a better option than a migration
(which will then typically take 10 years of customization to get the
same features that have evolved over a similar period for their current
application - but people tend to NOT factor this in as part of their
migration 'strategy')

As to the UI/Business Logic separation dilemma, whilst it is obviously
'nice' to have total separation (and in the process expose your
rules to SOA (Service Oriented Architecture if you aren't up on your
TLA's) opportunities or other emerging technologies, your own
'argument' ("I don't usually like to have my hands tied by
someone else's notion of what I should be able to do in code or how I
should do it") can be used ..... you can lead horse to water...

There is also an interesting variation to your last points - would
you use the data abstraction capabilities of a product like Visage when
developing your business rules? and/or would you use our
code/implementation abstraction capabilities of snippet technology to
define those rules?

I know you don't like me mentioning the "V" word, but there IS a
reason we market an Application Development Framework rather than a
simple IDE, though we don't force people into using these facilities.
Interestingly I don't think that our "Good design and forward
thinking" increase the cost of development as you suggest (I think
the opposite is true), but I can understand that if you were doing
this type of thing by hand/from scratch every time that it would be
'tedious'.

I'd like to think that the "product-specific nuances" we
facilitate are well founded, in theory and practical terms