Re: Newbie object design questions

From: CDX (cdy_at_noSpamDiceNoSpamHome.Com)
Date: 01/30/05

Date: Sat, 29 Jan 2005 22:40:54 -0500

So I'm going to hop back in on this one.

If MS wants to provide a quick way to delivery an app, ok. As you stated
there is a place for that. However most of the code that I've seen needs
to change. A good profitable business needs to adapt to a changing
environment. The one constant is change.

I think the large majority of business people who come to IT for a
solution do not understand what additional benefit can be added to these
systems. And before you jump on that, I am saying that these "features"
should be able to be put in after the initial project is done and only
if they are proved to be worth the cost of putting them in. Good
software design and development should allow for change.

A good software designer/developer should understand the business
implications of the system they are writing and should be able to offer
enhancements that will further boost the value of this project. Again,
the emphasis is after the initial project is done. Some additional
thoughts on that will follow as I try to describe some of the techniques
I use in development.

MS is misrepresenting this type of code as object-oriented. It does not
leverage the benefits of objects, rather it leverages frameworks. You do
not need an oo language to provide the code generation features that we
are discussing here. IMHO it undermines the true usefulness of oo design.

If MS wants to provide the quick code generation features for these
"80%" apps, ok, but don't misconstrue them as "Object-oriented". I
cannot see any large project using these frameworks. MS should have some
"real" oo frameworks in place for large projects that need a good solid
foundation for their systems. Persistence frameworks, UI frameworks and
domain frameworks, that can be easily glued together to form a much more
adaptable solution. If they do, they are not doing a good job of letting
us find them.

ok for some details on the development techniques that I use. I
absolutely do not agree with the large design, develop and release
cycles that you have seen kill projects. I agree wholehartedly that
those are not the way to go in today's world. A project that is going to
  succeed needs user involvement and understanding. It needs rapid
design, development and release cycles.

On our system, we often release several versions a day. Yes some may
include bug fixes, but a lot are either building blocks of features or
additional enhancements requested by users on the existing blocks of the
We maintain two to 3 versions of the code at the same time. A "Backup"
version, which can be run by the users in case something goes real wrong
with the production system and we need to essentially roll back code.
This gives them a quick way of falling back. The "Production" version of
the code is the stable code being used by the majority of the users. The
"Beta" code is used to test impending code releases in a production
environment and an Alpha version, which is used to either prototype new
ideas/concepts to specific users or to develop a new feature in tandem
with one or more users. (All of these version run again the production
data so that users can use either during the course of their normal
business day. They are actually using the Alpha version to do their
normal work as well). These users are very involved in the project
(larger projects are broken into small blocks and developed, release to
this group before the next block is moved to). They generally are the
users who request or directly benefit from the new enhancement. So they
tend to buy into the system because they get direct input into the
system, they understand some of the reasons why things can and cannot be
done (or should or should not be developed). The developers get
immediate feedback, so that we do not go down and wrong paths for very
long at all. Not only do we get good acceptance from the initial users,
but they tend to support the larger-scale rollout of the project, help
users to use and understand it's features, etc.

Of course the big problem that rears it's head in this environment is
feature creep. It is a problem that has to be watched constantly. But I
generally use this as input into future projects. The big question put
to all of these is "what's it do for the bottom line?". That is asked
directly to the user proposing it. Ok it helps you do your job better.
Does that necessarily make the company more profitable? More so than
implementing the other projects on the development schedule. If the
answer is yes, then it should be brought up the chain and offered. This
is where this process can really pay off. The close relationship with
the user and the developer can produce ideas that can really make the
project pay off. These ideas come about because of the process, not
because someone sat and "designed" a system to meet a specific business

ok, this is my soapbox. It really is not complete here, and there are a
lot of things missing (like how do I maintain three functional versions
of code working against the same data). Alot of those details lay in
experience, good tools and good, good frameworks.

ok, enough for this for now. I'm walking my way through the code I found
somewhere on how to put my business models into the datagrid frawmework.

Microsoft, got anything better for someone who is writing these 20%