|
I really would evaluate two or three components before buying, but it has been my experience that it is not always possible to find two or three components that fit with the requirements, the environment in which it will be used, etc., before purchasing one. Also, it often seems like there is a huge gap in the quality of components, even when you find two or three in a particular niche, one usually stands out as the clear leader, based on factors in addition to functionality -- the company's history in that niche, for example.
What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
|
|
|
|
|
John Kuhn wrote:
but it has been my experience that it is not always possible to find two or three components that fit with the requirements,
Actually, it depends on the kind of component we expect for and the environment we want it in. Either we get the search results as 2 or 3 as u specified, else we get more of them to confuse the selection process
He who controls others may be powerful, But he who has mastered himself is mightier still.
|
|
|
|
|
A big factor in my decision is does it come with full source as most 3rd party code I have used in the past had bugs that I discovered when incorporating it in my applications. Also, if the company closes I will be able to recompile it for future versions of windows if I have the source code.
John
|
|
|
|
|
So, that would eliminate most MS components, IE and MSXML for example?
|
|
|
|
|
Anonymous wrote:
So, that would eliminate most MS components, IE and MSXML for example?
Well, for me, that *is* a big reason. MSXML needs a certain version of IE to work right, and you have to run some funky merge modules to get it all installed on those systems, and it is a royal pain. And if your installer itself needs to parse XML, it's even worse... Not worth it when there are free, full-source alternatives out there (such as Expat.)
But many MS components have full source, such as MFC.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
You generally don't pay for MS components as they come with the deveopment package or a SDK. And some of them have full source code. As for bugs MSFT code is definitly not bug free. I have found bugs in windows, MFC, VC5, VC6, and .NET while developing my applications.
John
|
|
|
|
|
MFC is the only one that I know of with source code. Comes in handy when debugging. Even if it's a problem with your code stepping into the MFC source can give you an insight to what you are doing wrong.
|
|
|
|
|
Yes,I got the same idea with you
I am seeking...
For what?
Why did you ask me for what? I don't know!
|
|
|
|
|
I selected we don't use components.
What we do instead is try some components in non production applications and then after figuring out what is missing from the tools we have and the advantages the different components have, we then roll our own. Sometimes we are more successful than at other attempts but we generally come up with something acceptable.
This is because of a policy on the tools we use. We are not supposed to be supporting tools we didn't create, if a problem arises we will have to await info from tech support from different comppanies. Because of this, our component engineers have a tough time sifting through various commercial components trying to create something to address similar problem and if a problem comes up in an application because of a component, we have the people who made it to fix it for us ASAP.
Let's make things simpler than possible.
|
|
|
|
|
So we do.
First.
It seems to be quite rare situation when the component we need cannot be written by ourselves.
Second.
The rule is: the more critical functionality a component must cover the more important is to write it, not to buy.
hallelujah
|
|
|
|
|
Time is money. Sometimes much easier to buy 3rd party component instead of writing your own. Why not to use results of somebody's good work?
|
|
|
|
|
That's right. Time IS money. If you want quick start, you SHOULD USE 3rd party components. And perharps you will use VB or C# as the main tool.
If you've found modules that cover up to 90% of required functionality - USE THEM.
However many projects take time to grow enough to go to the market. And often developers have this time. It is very important to spend it well and get ready to lose less time (read - money) on support and maintenance.
Furthermore, if your product is a success, why not to sell it by parts you are the owner of? And let competitors run after you. Is your position on the market stronger, if your competitors are able to build their products on the same base as you did but paying not you?
But you're still right - time is money. With this in mind many developers "reuse" stolen code. Thus the component development is not that time consuming task as it seems.
hallelujah
|
|
|
|
|
We manage this because we have a number of people who devote their time to just making the components the rest of us will use in the end user applications.
Sometimes it is totally impossible to cope and then we have to use the 3rd party components, for instance when we use reporting and other graphics tools. Most of our people work on logic and other things and the graphics skills are not up to scratch but on the majority, we make our own components.
Let's make things simpler than possible.
|
|
|
|
|
In a word, the rule is: don't buy components if you can afford it...
hallelujah
|
|
|
|
|
Several cliches come to mind...
Let's re-invent the wheel...
Not invented here...
Sorry, but we also have had to fix our own stuff too,
and the company doesn't maintain anything forever...
Support is overhead and doesn't do much for the bottom line
(sort of like virus scanners... use resources that prevent
coorporative advances because you are trying to defend against
stupid people...)
Teaming arrangements and coorporating with others
seems to be a better approach...
Others have often solved some problems that we
would also be unaware of ...
Edsel
|
|
|
|
|
This is a true story; I'm anonymous today for obvious reasons.
Our marketing department - which overrides engineering on all decisions - determined that we would use a component created by another company that has a large market share in the particular realm we are working in. The fact that their app is a total piece of crap was not considered relevant.
Marketing specified that they would deliver a DLL, written in C++, along with source code.
The vendor - a single guy working out of his home - had never programmed in C++; all his work has been in VB. So he located a VB to C convertor, and then one of our team members - a contractor, as it happens - was assigned to help him convert this to C++.
You can see where this is heading. The contractor left; the DLL is a piece of sh*t. We shipped a month late because of this, and the release is buggy as hell as a result. Right now, our entire development team is focused on this DLL, trying to fix the most egregious bugs.
The sad thing is that we have neither legal nor moral recourse with this guy, because nobody gave him a spec, and because we paid him practically nothing. The marketer who pulled this off actually bragged in a meeting about how cheaply we were getting this guy! He has since moved on to another project, so we didn't have anyone to point the finger at in our post-mortem.
|
|
|
|
|
Outsourcing Marketing could realize a significant savings for your company. Be sure to mention this possibility to your management and claim the savings as an accomplishment on your next review.
Will Build Nuclear Missile For Food - No Target Too Small
|
|
|
|
|
Anonymous wrote:
Our marketing department - which overrides engineering on all decisions
Tell them to code, too
BTW, ask them to help debugging that lost pointer the VB coder left on the DLL...
I see dumb people
|
|
|
|
|
The whole purpose of using components is to save time. If I had time to test every component out there that might do what I need, well, I might as well write my own.
In reality, though, most components would be weeded out before we even pick one. All source code has to be available, for instance... won't even consider a closed component. We also tend to have strict dependency requirements... if it won't run on 98 or NT 4, it's out. It should be self-sufficient, if it depends on msvcrt.dll or mfc42.dll, or any other funky DLL that might not be on all target systems, and can't be changed to avoid those dependencies, it's out.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|
|
Alot the same here. We will never buy a non-source version. And it has to be .NET and C#/C++ - no VB.NET or COM.
|
|
|
|
|
Hi, Eon:
Why don't you like COM? Could you give us a few explanations? I think that COM is a classic and approved technology. If the COM is written from C++/ATL templates, its quality should be fine to us. Further, you can reuse it everywhere, and even with dotNet.
Regards,
Yuancai (Charlie) Ye
|
|
|
|
|
Nothing against COM at all - I used to do alot of under-the-hood ATL development a few years ago (and I still love it). I personally prefer COM to the built-in .NET remoting code.
Our company's focus is however not the dev of components, and we do mostly web-based sollutions. Using COM tends to cause an extra layer that we don't use, since all our code is pure .NET, and the framework as-is is good enough for that.
We prefer using pure .NET components, thereby minimising the dependency on external sub-systems like COM+ and some of the older VS6 dll's.
|
|
|
|
|
Navin wrote:
The whole purpose of using components is to save time
Navin wrote:
We also tend to have strict dependency requirements... if it won't run on 98 or NT 4, it's out. It should be self-sufficient, if it depends on msvcrt.dll or mfc42.dll
Do u have time to put on those systems and check 'em all
I was born intelligent Education ruined me!.
|
|
|
|
|
S P S wrote:
Do u have time to put on those systems and check 'em all
Actually, that is pretty quick. Typically stuff breaks immediately... or the component says they're not supported.
Remember, even if you win the rat race, you're still a rat.
|
|
|
|