not quite off-topic
I'm developing an ActiveX dll that essentially operates as the data access
and business logic layers for an enterprise system. I'm well past the whiteboard
stage of the project. However, I'm still worried about the decisions my
team (mostly I) made regarding the logical structure of our system.
I've been working with Visual Basic since 1993. I have mastered the code.
In seven years, I haven't yet mastered the whiteboard. Put another way,
I can build any house from the blueprints, but I can't draw the blueprints!
How do *you* make design decisions? Where do you go for ideas? Where is
your assurance that you're either right or pretty close to it?
What I consider most frustrating is the situation in which I now find myself.
My design decisions are only right because I haven't managed to prove them
wrong yet - and I don't feel very confident in my ability to prove myself
Re: not quite off-topic
This is definitely not off-subject! What excites me about this post is that
it shows your desire, from within, to design not just a solution, but the
correct solution. This is what professional software development is all
What you are describing in your post are two different aspects of the software
development process: programming ("buiilding a house from blueprints") and
architecture ("drawing the blueprints"). Your use of the term "blueprints"
is perfect since that is what architecture produces. There has recently
been more and more discussion about software architecture. Check out an
article right here on DevX by Marc Sewell that discusses this topic (http://www.devx.com/upload/free/feat...00/sa10500.asp).
There are many ways to design and implement almost any system, including
wrong ways. Since you are developing an ActiveX DLL, it makes the job, in
one key way, a little easier. When designing an ActiveX object, you really
have two areas that you need to design: the ActiveX interface (the public
Events, Methods, and Properties seen by the consumer of the object) and the
internal workings of the object. The nice thing about objects is that the
consumer of the object really doesn't care how it is designed internally,
as long as it works.
If you are concerned about the public interface of the DLL, then you should
focus on how to best solve the user's problem (the user in this case is the
consumer of the ActiveX object, probably you). Can you provide an object
that solves the problem that required an ActiveX object in the first place?
Does it do this without involving the consumer in the messy details of how
the object works internally? If so, then you have probably designed a great
interface. Since software development is the blending both art and logic,
you have a lot of room for creativity in the design of your interfaces.
If your interfaces will perform some tasks that are similar to other objects
on the market, you should attempt to make the syntax similar. Other than
that, you are free to be as creative as you want to be. What you really
want to do, when designing an ActiveX object, is to make it very simple for
the user of the object, even if that means increasing your programming effort
within the object's black box.
If you are concerned about the design of the internals of object, then you
should focus on correctness and efficiency. (There may be other concerns,
such as security, that must be addressed as high-priority issues in your
specific circumstance.) When you implement an object, above all you want
it to be bug free. Also, you want it to be efficient for the consumer of
the object; you don't want the consumer to wait for seconds for an activity
when a differently-written version of the object could do the same job in
a fraction of a second. As long as the object works well and efficiently,
the consumer does not care about the torture you had to endure to design
I spent parts of my childhood in both the blizzards of the Rocky Mountains
and in the deserts of the Southwest. In my house in the mountanis, the central
heating vents were placed along the floors in all of the rooms of the house.
When I moved to the desert climate, I found that all of the air conditioning
vents were on the cielings instead of the floor. Of course, both types of
houses were built properly, although the blueprints that included the central
air portions of the house were different to meet the climate needs of each
location. To ask "should vents be on the floor or cieling; which is correct?"
as a general question is not necessarily valid. It depends on the place
where you are building the house. In the context of ActiveX DLLs, how you
design the object depends on the environment into which the object will appear
(the consuming application).
My wife and I are thinking about remodeling our bathroom (the one with the
1960's medium-blue bathtub and matching toilet). But this does not mean
that the original design of the house was faulty. We are only changing the
internals to address issues that were not there when the house was built
(like good taste in color schemes). The "interfaces" to the bathroom will
not change. If your team has taken the time to actually design the interfaces,
then you should place a lot of confidence in the logic of your system. You
may have to re-address portions later to account for issues that you could
not see in early design. But that does not mean that the design is invalid.
As long as you are efficiently and correctly solving the problem that prompted
the software, you have succeeded.
By Charles Kiley in forum Careers
Last Post: 08-14-2002, 04:38 PM
By Marion Elledge in forum XML
Last Post: 04-17-2001, 03:20 PM
By Jim Anderson in forum Enterprise
Last Post: 01-29-2001, 04:33 PM
By T. Hoskins in forum Enterprise
Last Post: 01-28-2001, 08:28 PM
By Richard Dalton NA in forum Talk to the Editors
Last Post: 12-15-2000, 10:11 PM
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center