Survey Results

FirstPrevNext

Use of 3rd party controls depends... LongRange.Shooter24-Oct-02 9:22 LongRange.Shooter 24-Oct-02 9:22  We have very rigid timeframes for getting apps out. It gets hard to do this when everyone is still learning the guts of .NET. Sometimes I dive into writing my own control to do what I want. If I hit a snag I go off to GOTDOTNET to see if someone has an answer. (after searching MSDN for an hour) But to do something outside my realm (put in a cool, graphic control that I have no artistic ability to create myself) I will use a 3rd party control. The company I am a part of also have purchased an enterprise license with one vendor that gives us some good controls as well. So we will use those controls outright. Other controls....they have to be free and provide source code. Need Choice: I only use third party controls when source code is supplied. NormDroid23-Oct-02 22:48 NormDroid 23-Oct-02 22:48  If our company want's to use a third party piece of component I always recommend the company that ships the source/documentation with the component. Developing with C++ is like programming by the seat of your pants Who's the 2nd party? Marc Clifton22-Oct-02 7:17 Marc Clifton 22-Oct-02 7:17  Must be Bill. And I don't trust his components either! Marc Help! I'm an AI running around in someone's f*cked up universe simulator. Re: Who's the 2nd party? peterchen22-Oct-02 13:18 peterchen 22-Oct-02 13:18  the client, usually Auch den Schatten will ich lieben weil ich manchmal lieber frier'  Rosenstolz   [sighist] Re: Who's the 2nd party? Troy Marchand23-Oct-02 7:23 Troy Marchand 23-Oct-02 7:23  So if a component vendor OEMs another vendors component, does this make it a 4th party component ??? Decision factors Troy Marchand22-Oct-02 5:30 Troy Marchand 22-Oct-02 5:30  This is a general question for everyone who reads this: What are the general decision factors you use when determining when to use a component or not? (Complexity, ROI, turn-around time, etc.) And what criteria do you use to choose between similar components? (Price, quality, support, learning curve, etc.) Troy Marchand VP Component Development Dundas Software Re: Decision factors Gary Wheeler23-Oct-02 1:45 Gary Wheeler 23-Oct-02 1:45  Troy Marchand wrote: What are the general decision factors you use when determining when to use a component or not? (Complexity, ROI, turn-around time, etc.) Generally, we will use a component when the required functionality is too expensive to develop in-house compared to the costs of adapting to the third party component. If we develop the component in-house, we get exactly what we want, but this approach is expensive in terms of manhours spent developing the component. If we buy the component, we spend manhours learning how to use it, and adapting our needs to the functionality the component provides. With purchased components, you also have to weigh the risks inherent in support from an outside vendor. If you need additional functionality (or bug fixes) that only the vendor can provide, you are constrained to their abilities and schedule. And what criteria do you use to choose between similar components? (Price, quality, support, learning curve, etc.) Add prior history or experience with the vendor and customer needs (some customers may dictate compatibility with 'Company X'). Performance can be an issue in some cases. Software Zen: delete this; Re: Decision factors Paul Watson23-Oct-02 3:21 Paul Watson 23-Oct-02 3:21  Gary Wheeler wrote: Generally, we will use a component when the required functionality is too expensive to develop in-house compared to the costs of adapting to the third party component... I agree with that whole paragraph. Paul Watson Bluegrass Cape Town, South Africa Re: Decision factors Gary Wheeler23-Oct-02 3:56 Gary Wheeler 23-Oct-02 3:56  One of the problems I have with management where I work is third party software. The management here seems to think that using third party stuff is 'free', except for what you pay to the third party. They never recognize that third party stuff does have a cost associated with it. "You're using 'XYZ', so why aren't you done?" "Well, we first had to learn to use 'XYZ', and then we found out it doesn't do 'abc' so we have to emulate it. We also found out that when we 'def' they GPF. We've got a bug report in to them, but they haven't responded yet. In the meantime, we've developed a workaround, but it means 'blah' feature in our product won't work quite the way we planned." I don't object to third party software at all. I just dislike the notion that it's something for nothing. And so it goes... Software Zen: delete this; Re: Decision factors Ed Gadziemski25-Oct-02 5:01 Ed Gadziemski 25-Oct-02 5:01  We've got a bug report in to them, but they haven't responded yet. Don't you mean they haven't responded 'asap'? Re: Decision factors Gary Wheeler25-Oct-02 7:29 Gary Wheeler 25-Oct-02 7:29  ASAP = As Soon As you Pay for that level of support. In my experience, the only time you get a bug fix out of someone like this is if you have a separate and distinct contractual relationship with them. If all you've got is a retail relationship, they have neither a need nor an obligation to fix things according to your schedule. Software Zen: delete this; Re: Decision factors Troy Marchand23-Oct-02 6:26 Troy Marchand 23-Oct-02 6:26  Generally, we will use a component when the required functionality is too expensive to develop in-house compared to the costs of adapting to the third party component. If we develop the component in-house, we get exactly what we want, but this approach is expensive in terms of manhours spent developing the component. If we buy the component, we spend manhours learning how to use it, and adapting our needs to the functionality the component provides. With purchased components, you also have to weigh the risks inherent in support from an outside vendor. If you need additional functionality (or bug fixes) that only the vendor can provide, you are constrained to their abilities and schedule. Hey, thanks for the answer. This seems to be a common sentiment among developers, and is an area we have been working very hard to address over the past year. Being a long time developer myself I understand this situation all too well. I personally use the 15 minute rule ... if I cannot get a component to 'basically' work in 15 minutes it is a waste of my time (Now there are exceptions to this rule, such as a component that performs a really complex task that would not be practical to create myself). Developers just don't have the time to play with a control for a week to see if it 'might' work with their project. I think that one of the biggest problems is that most component companies "do not eat their own dog food!" They build these components, try and sell them to other people, but have not really used them extensively in real-world projects themselves. Trust me, our consulting group gives us loads of feedback and has made us rethink how we write our components. Plus we rotate our developers between the consulting product and support groups, so they can eat what they made! Troy Marchand VP Component Development Dundas Software Re: Decision factors Gary Wheeler23-Oct-02 7:11 Gary Wheeler 23-Oct-02 7:11  I like the idea of rotating developers between business groups. Unfortunately, given the long development cycles for our products (12-18 months) and the long maintenance intervals (we have applications that are over 10 years old that are still maintained), it isn't feasible to move people about on any kind of regular basis. Software Zen: delete this; Re: Decision factors Troy Marchand23-Oct-02 7:22 Troy Marchand 23-Oct-02 7:22  I like the idea of rotating developers between business groups. Unfortunately, given the long development cycles for our products (12-18 months) and the long maintenance intervals (we have applications that are over 10 years old that are still maintained), it isn't feasible to move people about on any kind of regular basis. We generally do not move people around during a development cycle; instead we do it in between. Also we only a small portion of a team would be changed at any one time, to ensure that there are still key developers working on it. Plus any person who is moved would still be made available to help the old team if needed. Here at Dundas all of the groups work very closely together, so that we can get the benefit of each others knowledge. Troy Marchand VP Component Development Dundas Software Dependency issues Rob Caldecott21-Oct-02 1:50 Rob Caldecott 21-Oct-02 1:50  3rd party component dependencies can also be an issue. For example, you probably wouldn't want to use a component that depends on MFC if you are shipping a WTL app! Years ago, we used to use the BitsPerSecond Graph control - but this required all the usual MFC DLLs to be shipped, and the app we wanted to use it with was plain old vanilla Win32/C. In the end we wrote our own graph code. Consequently I will only consider 3rd party components if they are written in plain C++ - I chose the Dundas Ultimate TCP/IP library for this reason. Faith. Believing in something you *know* isn't true. Re: Dependency issues Navin21-Oct-02 9:47 Navin 21-Oct-02 9:47  No kidding. Anything that dynamically links to MFC42.DLL or MSVCRT.DLL is out. Period. Dependencies on different versions of IE can be frustrating too... I can understand being dependent on IE 4.0 or greater, since it comes with Wininet and many other DLLs that are now "standard", but that's about it. Even a broken clock is right twice a day. Re: Dependency issues peterchen22-Oct-02 13:19 peterchen 22-Oct-02 13:19  What about "IE5 or above" ?? Auch den Schatten will ich lieben weil ich manchmal lieber frier'  Rosenstolz   [sighist] Re: Dependency issues Navin23-Oct-02 3:00 Navin 23-Oct-02 3:00  I can't remember if 2000 and/or 98 come with IE5. If so, then that's not *too* bad. Certainly not IE6 or above. Even a broken clock is right twice a day. Re: Dependency issues peterchen23-Oct-02 10:09 peterchen 23-Oct-02 10:09  W2K & 98 SE yes, 1st ed no IE5 has far improved DHTML access from the outside, which we need now and then. Navin wrote: Even a broken clock is right twice a day. Which you can't say of most clocks that "work". nonetheless people seem to prefer them Auch den Schatten will ich lieben weil ich manchmal lieber frier'  Rosenstolz   [sighist] Depends on Cost & Client Paul Watson20-Oct-02 23:15 Paul Watson 20-Oct-02 23:15  Nine times out of ten it is cheaper and quicker for us to write our own components because nine times out of ten the problems we face are not that difficult. It is only when we come up against something that will take a solid month or two to figure out and code that we will hunt for a component that does it for us. Remember that cost of training and implementation with 3rd party components is quite high while with having written your own component the cost is much lower. Also being in web dev we get the odd client who refuses to allow any 3rd party components on their servers. Even if we are hosting the solution some clients do not want 3rd party components for fear that the component manufacturer will go out of business and they will be left with an unknown component. All I can say is thank god the .NET Framework has some fundamental components which normally required 3rd party components in ASP (.e.g uploading, image manipulation etc.) Paul Watson Bluegrass Cape Town, South Africa Re: Depends on Cost & Client Troy Marchand21-Oct-02 8:48 Troy Marchand 21-Oct-02 8:48  So... what is the difference between a third-party component vendor going out of business, or you (as the developer) moving on to something else?? Would the availability of source code be the issue? Plus, now that .NET components run in a secured manner, would you be more willing to use them, since they allow X-Copy deployment? I don't mean to annoy you with all of these questions, but as a person in a component development business the more I understand what developer's wants and concerns are the better. Troy Re: Depends on Cost & Client Paul Watson21-Oct-02 20:40 Paul Watson 21-Oct-02 20:40  Troy Marchand wrote: So... what is the difference between a third-party component vendor going out of business, or you (as the developer) moving on to something else?? Good point. But there is a difference in the relationship between us and the client, and the client and the 3rd party component developer. First of all most clients check to see if we are an established company and looking to be around for a good time to come. They cannot really do that with 3rd party component developers that we want to use as they do not know much about them. Sure we could, for the client, check up on the component developer, but no client is really going to be 100% trustful that our checks are thorough. And so they shouldn't be because we do not have the resources to do a thorough check. Also we give a warranty period on any project we do and that is between us and the client. With a 3rd party component any warrantys, guarantees, support etc. is between us and the developer, not the developer and the client. Another thing is that there is more "proprietary" knowledge required in using a 3rd party component than, lets say, doing it straight in ASP or whatever the language it is. So if we did go bang and the client needed some more work done and a 3rd party component was used then the client would have to invest more money into either finding someone who had used the component, or invest more money into training their new developers in the workings of the component (plus of course the project we provided itself. ) Other issues surround support (once again the support agreement is between you and I, not you and my client) and liability. All in all some clients refuse 3rd party components. Others refuse to allow 3rd party components unless source code is provided (but some back out of that route when they see the price for getting the source code .) Troy Marchand wrote: I don't mean to anoy you with all of these questions, but as a person who a component development business the more I understand what developer's wants and concerns are the better. Not annoying at all and I enjoy fleshing out my own thoughts on the matter. And I am always happy to help out fellow developers. We as a company would never get into strict component development (we may release components but they would be for free and more as a marketing thing than a cash generator) but effectively we do do component development and use them in all our projects for clients. Some call it re-usable code Paul Watson Bluegrass Cape Town, South Africa Depends on free time... Philip Patrick20-Oct-02 21:59 Philip Patrick 20-Oct-02 21:59  If I have enough time to make my own, I'd prefer to do it rather than use someone else's. This way I can also learn new things Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer And only with the source code... George20-Oct-02 18:46 George 20-Oct-02 18:46  With the amount of the spy-ware we have nowadays I only trust and use the components that come with the source code. Anything else seems to be a plain suicide. <center> /* I C++, therefore I am... */ </center>

Last Visit: 31-Dec-99 18:00     Last Update: 22-Mar-23 6:29 Refresh 12 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.