[AccessD] Framework Discussion - Who's following this

Ken,

>Deciding what the framework will and won't do beforehand guides
development, and helps keep feature bloat from delaying a timely finish.

Yea... in a perfect world.  Unfortunately for most of us a framework is not
a project which we spec out and write, but rather a living entity that we
add functionality to on a weekly basis.  Thus feature bloat is an inherent
part of doing business, and there is never a finish, much less a timely one!
;-)

>Write code that is spare, obvious and well thought out, like Shaker or
Biedermeier furniture.

And never reference things like Biedermeier furniture without copious
comments as to what the heck it might be.  <grin>

>Accept the limitations of your platform. Frameworks can't make up for
system shortcomings.

I understand what you are saying (and your example is a perfect one),
however I think it is important to NEVER accept the limitations of your
platform.  Much of what my framework does is nothing more than an attempt by
me to program around the limitations of Access.  To the degree that I
succeed, I make myself (or my framework) more valuable to my client.  If I
fail to make the attempt then I end up just another developer, building just
another app, with nothing to differentiate me from the next guy to walk in
the door.

furthermore:

* Comment, comment, comment!
* Use conventions.  There are many levels to conventions from object naming,
to interfaces between objects, to systems for troubleshooting, to the way
forms and controls behave across the application.  Develop them and then
apply them consistently.  There is nothing more frustrating to a user than
an application where behaviors like NotInList work here but a bizarre Access
error message pops up over there.

Thanks for your input Ken, I am hoping to get more people with your level of
expertise to pipe up with their collective wisdom.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Ken Ismert
Sent: Tuesday, March 09, 2004 3:38 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Framework Discussion - Who's following this



1. a
2. a
3. a

Three suggested guidelines for frameworks:

 * Simplicity drives adoption. No matter how complex the framework becomes,
if it is made of small, easy-to-validate parts, it will tend to be reliable
and maintainable. Well-factored code, careful choice of object boundaries,
and attention to naming makes the framework easier to understand and use.
 * Define boundaries. No matter how well thought-out and abstracted a
framework is, perfect generalization is elusive. Deciding what the framework
will and won't do beforehand guides development, and helps keep feature
bloat from delaying a timely finish.
 * Accept the limitations of your platform. Frameworks can't make up for
system shortcomings. If VB doesn't shutdown an application opened through
automation when you set its reference to nothing, there is nothing within
the system that you can do to fundamentally fix it. You can write standard
handlers for such situations, but you can't force the user of the framework
to use them. In cases like this, education is the best approach.

Write code that is spare, obvious and well thought out, like Shaker or
Biedermeier furniture.

-Ken

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com