Newbie object design questions

[Mike Ryan]

Chip(ster),

I still think this is due to a lack of information and that you'll be
able to find solutions for these problems.

Some of what you're discussing reminds me of the (elusive) ObjectSpaces
project:

http://msdn.microsoft.com/data/objectspaces.aspx

That won't help now, but certainly there are other options.

It might be helpful if you (and Bruce) can describe strategies, tools or
frameworks you might have used--in Smalltalk, Java, C++ or
whatever--that you're not seeing in .NET. An example might be something
like Java's Hibernate project, which has a counterpart for .NET.

- Mike

 

[Bruce Wood]

Chip,

I know that I hardly have the experience to make such pronouncements,
but I think that Microsoft's strategy is, as it has always been, to
target to the 80%.

For most business applications, a carefully-crafted business layer that
is truly independent of the data layer is overkill. People want to be
able to whip together a report in a half day, mostly because if they
tell their bosses that they have to build business layer objects and
then connect them to the blah-blah-blah, and the guy at the next desk
says, "Oh, I can drag and drop that in half an hour," guess who is
going to impress the boss?

And you know what? It's probably sound engineering in most cases, too,
because putting a lot of energy into carefully crafting a beautiful
three-tier model involves taking the risk that it will all be worth it
in the end. Maybe the business is more interested in a build-it-quick
and then throw-it-away-and-rebuild-it model of development. I used to
think that that was nasty and wrong, but I've seen it work since.

I'm also sure that, as Mike suggests, MS has a strategy for those
situations (the other 20%) in which careful engineering of three
cleanly separated layers is called for. I just suspect that it's not as
strong as their strategy for rapid development of medium-well
engineered code.

MS / Bill Gates have always given people what they wanted, even if it
wasn't the most beautiful solution. In this case, what the people with
the money want is a way to build a quick little client / server app in
two hours. Take my workplace for example: What's the #1 complaint of
the business? IT takes too long to deliver solutions. It's not that IT
spends too much time on maintenance. That's secondary. So, along comes
MS and says, "Look: drag and drop, instant client / server app." Sure,
it's not the best-engineered client / server app, but it's pretty good,
and "pretty good" is good enough.

I got myself into this discussion because I am very interested in
MS's strategies, and how they think we should tackle some of the more
difficult programming problems in a business environment. Even though I
see them more as an "expedient programming" company, I still think that
for the size of shop we're running here, they're the only realistic
choice. It makes sense for us to leverage off of a lot of smart people
in Redmond, even if they do things differently from how I would choose
to do them.

OK... I'll get off my soapbox now....

 

[Mike Ryan]

Bruce,

And you know what? It's probably sound engineering in most cases, too,
because putting a lot of energy into carefully crafting a beautiful
three-tier model involves taking the risk that it will all be worth it
in the end.

I agree. On a recent project the customer wanted us to essentially build
them a development environment/application builder, so they could design
custom forms, create tables, and a bunch of other features. Well we
already have such a tool, and it's called Visual Studio. How much money
do you think MS spent developing that?

The organization would never realize a return on such an investment, and
it made much more sense to have developers implementing any (infrequent,
as admitted by the customer) changes as required.

Maybe the business is more interested in a build-it-quick
and then throw-it-away-and-rebuild-it model of development. I used to
think that that was nasty and wrong, but I've seen it work since.

Have you read recently about the problems with the FBI's case management
system? The contractor worked on it for a few years and by the time it
was delivered it was already outmoded:

http://www.gcn.com/vol1_no1/homeland-security/31432-1.html

I've personally encountered several such projects in recent years, each
time a team using Java and RUP to build a monolithic
system-to-replace-all-systems. About a year and a million dollars later,
what they've produced are some outdated documents. Then we come in with
a small team and get the job done quickly and cheaply. The system may
not be as comprehensive, but if you can get there with a usable system
offering 80% of the desired functionality for a fraction of the cost,
then you've gone a long way toward a successful project. And 80% of
something is better than 100% of nothing.

And it seems funny, too, that we're working in the "evil" Microsoft
world yet we've ended up being the ones delivering working software,
collaborating with customers, and responding to rapid change:

http://agilemanifesto.org/

Again this is just my own experience, and I may be unfairly singling out
a particular technology here--certainly the process is more important
than the tools--but that particular process seems bound to that
particular technology and I believe it creates negative perceptions
about the effectiveness of that approach (much like programmers outside
the Microsoft world have perceptions about its technologies; and btw, I
_like_ Java!).

I think it always comes down to requirements. Use as much code and
process as is required to get the job done. When you're "building the
space shuttle"--an oft-cited example from a former co-worker--you
certainly approach the project differently than a more mundane business
application.

I'm also sure that, as Mike suggests, MS has a strategy for those
situations (the other 20%) in which careful engineering of three
cleanly separated layers is called for. I just suspect that it's not
as strong as their strategy for rapid development of medium-well
engineered code.

Spot-on again, in my opinion. I'd expect no less from a man who uses the
word "gerund" in a sentence.

What's the #1 complaint of the business? IT takes too long to deliver
solutions.

I often say that in IT we concentrate too much on the "T" and forget
about the "I."

As a database programmer my job is to build information systems to help
customers make better decisions. They don't pay me to play with toys.
Information systems don't require the "T" and for many years were just
constructed on paper.

So, along comes MS and says, "Look: drag and drop, instant client /
server app." Sure, it's not the best-engineered client / server app,
but it's pretty good, and "pretty good" is good enough.

Some technologies only give us one option: code-your-own. MS gives us
that option, but also provides a faster way to deliver simpler systems.
If that additional option creates misconceptions about the craft of
software development and leads to unrealistic expectations on the part
of customers, then that may be a valid criticism. But I can't fault MS
for giving us that option.

OK... I'll get off my soapbox now....

What were we talking about again? Ah yes, business objects. It all
started in 1904 . . .

- Mike

 

[CDX]

ok,
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
system.
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
need.


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%
apps?????

Chip

 

[Stefan]

Hey CDX,

We use the same techniques as you at my company. We maintain a couple of
versions of all our code VB 6.0 and SQL, and release builds almost
daily, eithier to release new features or fix bugs users complain about.
Our project (an ERP) is maintained in Source Safe and we wrote a
versioning app which pushes the new builds (*.dll, *.ocx) out to our
clients on the network as necessary.

YOU WROTE:

{ 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. }

As you mentioned above our company works the exact same way.

Happy Coding,

Stefan
C# GURU
www.DotNETovation.com

"You always have to look beyond the horizon and can never be complacent
-- God forbid we become complacent."

Jozef Straus

 

[Bruce Wood]

A few comments about your post.

If MS wants to provide a quick way to deliver an app, ok. A­s you stated
there is a place for that. However most of the code that I'v­e seen needs
to change. A good profitable business needs to adapt to a ch­anging
environment.

Yes, but remember that Microsoft's primary purpose is and has always
been to _sell software_. This is why MS is so successful and Apple
wasn't: Mr. Gates recognized that producing a beautiful product was
secondary to getting people to buy it. As you later remarked, "...the
large majority of business people who come to IT­ for a
solution do not understand what additional benefit can be ad­ded to
these
systems," and therefore don't understand why they should be shelling
out more money, and waiting longer, for that benefit.

As well, don't forget that MS has a target market. Maybe they're not
after the huge Fortune 500 companies that have entire armies of
programmers and projects that span decades. Maybe they're after small-
to medium-sized businesses. I don't know: you'd have to ask their
marketing department. As such, they target their tools and the features
to the market they're after.

We're a small operation, for example. One of our business managers was
banging his drum about ditching our system and rewriting it on Linux
using Java. I told him flat out that he was nuts. Java requires clever
people (although not as clever as C++ requires) who are willing to
write and architect pretty-much everything themselves. That requires
big $$. MS, for all of its faults, holds you by the hand with lots of
books, courses, and web seminars on how to use their products. This in
turn means that it's cheaper to bring programmers up to speed.

MS also has lots of rapid-development options for throwing together
applications quickly, although I'm still trying to get my head around
them (which is why I'm posting here). This also makes development
easier.

But, as you ask, what about change? Well, if I can write in two hours
(using MS's quick-and-dirty drag and drop software) and application
that would take you two days (using proper O-O techniques), then I can
afford to throw that app away and rebuild it eight times before it
becomes more expensive than yours. That's another way of responding to
change. As I said, I used to loathe that attitude, but I saw it work at
one company I was at.

Of course, that approach fails in the aforementioned huge companies
with armies of programmers: it quickly gets out of hand. However, in a
little shop like ours, it could work, and maybe we're MS's target
audience.

As far as MS marketing their rapid-development tools as
"object-oriented"... c'mon... how long have you been at this? Can't you
hear the Marketing department talking there? When's the last time
you met a Marketing department that: 1) got along with Engineering; 2)
was concerned about the precise use of language; 3) particularly cared
about being accurate?

I don't know whether MS produces anything that would fit the way you
develop software. Then again, (and this is my last point... promise
I have to ask who does? The Java world "does", but only by virtue of
the fact that you have to build the entire stinkin' thing yourself. You
could do the same thing in C#. The C++ world doesn't, so far as I know.

I'm wondering if your question doesn't boil down to, "Does Microsoft
provide tools for building my sophisticated, multi-tiered,
object-oriented application that are as good and as easy to use as the
tools they supply for building quick little drag-and-drop
applications?" I don't know the answer to that one, but in a way isn't
it expecting more from MS than one expects from, for example, Sun or
IBM?

For my part, if I worked for some huge bank, I would probably recommend
that they go Java, because they have the big bucks and even though it's
more laborious, it's a more proven technology.

However, where I am, I'm interested in what MS provides out of the box.
If the answer is, "Rapid development tools for building two-tiered apps
that embed the database schema in the UI," then I'll have to think
about the risks and benefits of that approach.