views:

463

answers:

14

There is a guy I work with who has been tasked with getting a grid hooked up to a database. There has been some problem with the performance of the built-in grid and we are looking for alternative solutions.

I have suggested (and my manager has backed me up) that we try testing 3rd party grids such as Infragistics, XCeed, Telerik, or any of the dozens of other grid vendors out there.

My co-worker has started working on his own custom solution and used the following arguments as to why he hasn't 'gotten around' to downloading the trial versions:

  • Need the source code so we can customize
  • Confident that the 3rd party grids won't perform as well as a hand-rolled solution
  • Doesn't think that 3rd party grids can connect to our data source

Now, I will admit that we are using SharePoint and ASP.NET, but I am looking for a platform agnostic approach to the problem.

How do you convince a developer to at least explore 3rd party controls before building your own?

+4  A: 

My advice: Show, don't tell.

Use it yourself and show what it can do.

It's one thing to say, "You should use this. It looks neat." It's entirely different when someone has gone to the trouble of adapting it to fit the project and shows off how easy it makes things, how much documentation there is on ways to expand upon it, etc.

If the developer is just too stubborn to go with an off-the-shelf solution, you might have to go a different route... Some people are just convinced that their way is the right way <shrug>

Custom solutions are great for making things do EXACTLY what you want, at the cost of development/support time. Stuff like Infragistics have a LOT of functionality that will give you the bulk of what you've wanted, but at the expense of needing to work around their ways of doing things.

At the end of the day, it's about what's best for the business... and, chances are, there are more people familiar with 3rd party solution 'X' than with an in-house component your co-worker wrote.

Kevin Fairchild
+4  A: 

For some of the 3rd party controls like DevExpress, you can buy their source code too. That should help in reducing some fears about lack of control.

Gulzar
+1  A: 

There are the kind of arguments I would use:

  • Ask him how much value he finds in re-inventing the wheel
  • If he really thinks that his UI widget solution would really be all that much better than what people who are paid to produce UI widgets can do
  • If it's really in the company's best interest and if it helps the bottom line for him to be coding UI components

I'm guessing your company does not make money by producing grids or reports, but has some other different type of business.

Of course it also depends on how much $$ these components cost, if they are not free.

matt b
+1  A: 

This is difficult in all environments. A person should be naturally exploring (researching) to maximise value to his employer rather than lock in through legacy code.

I suggest that you need to take steps to guide this employee away from deviations and inevitable delay (and we all know crticisms for not delivering) by having some sort of insentive to bring solutions fast, even if it costs money by using 3rd party components etc.

Of course there is the hard way - performance management, ultimatims, serious talks, target setting etc. but I believe a more guiding approach initially.

mm2010
+9  A: 

Hit him with a stick, because he's obviously too thick to see reason?

It's always fun to re-create the wheel, because it's new to the developer, and not as boring as cranking out their 800th report/web page/DTS package. However, it takes hundreds or thousands of hours to create a truly flexible tool -- hours that your company certainly doesn't want to pay for. There's zero business value to recreating commodity controls, and a lot of project risk.

He may be able to make something more performant than the off-the-shelf solution. However, I'm guessing it won't be as flexible, reusable, cross-browser compliant, or (most importantly) bulletproof as an off-the-shelf component. And if your data is so wonky that other controls won't be able to bind to it, then he serve the mission better by wrapping that so you can reuse the logic.

Danimal
A: 

A situation like that can be very frustrating. Some people just won't budge, even when you politely remind them to not reinvent the wheel. Having your manager on your side is a good thing, because at this point, it should no longer be your responsibility to convince him - it should be your managers.

unforgiven3
+1  A: 

Compare costs. After all, in a company, it's all that matter.

Ask him to evaluate the timeline to achieve your requirements needs, and then compare its salary to license fees (adding the fact that during this time, he won't be affected to other tasks, which also cost money!). I'm pretty sure he'll be more expensive than existing solutions.

As being more expensive, you can, if needed, ask him to perform evaluation of existing tools. Evaluation don't cost that much (regarding to all the other part of the budget). He might be surprised by out of the box solutions.

gizmo
A: 

Covered in this thread...

The upshot is that it may be appropriate to eschew 3rd party solutions. However, you would definitely need to make that decision with knowledge of the alternatives...

Jeff Kotula
A: 

It depends on the functionality you need. Most asp.net controls have crap api's and do way more than you need them too. They also generally reinforce bad coding practices. The best part is, when you want to tweak the control to do something just outside of the box, you can't.

If you only need minimal functionality and you have competent developers, you're better off rolling your own.

bmavity
+2  A: 

There are times when it's best to build in-house, and other times when it's best to buy. The hard part is to make that decision based on the right criteria. The programmer thinking that this is a cool project that he'd like to work on isn't the right criteria.

If the boss has already made the decision to go with a 3rd party control, there's no need to "convince" the programmer of anything. He just needs to be told that this is the decision and that it's his job to do as he's asked.

If the decision hasn't actually been made yet, then the question is still open for discussion.

If the programmer has already made up his mind that his way is best, it might be better for someone else to investigate the 3rd party controls and let him continue building his version. Both programmers can create prototypes, and they can be compared at the end to see which is better.

"Better" would need to be defined before starting though. I'd say it should include things like depth of functionality, performance, time to market, and cost.

Don't let this guy convince you that his cost is zero. Unless he's working for nothing, his cost is equal to his rate of pay. His cost also includes time supporting/training others in the use of his tool, plus maintaining it over time.

Clayton
A: 

How do you convince a developer to at least explore 3rd party controls before building your own?

Well, if you are the person's manager, the ultimate way is to give a clear direction - "you will not develop your own solution, but investigate these other options". Sure, we all like to work in a gentle friendly environment, but as a manager, you are being paid to manage, to set the directions and strategy, and you need to exercise that managerial authority.

Now, if you aren't that person's boss, but just a co worker, there's not much you can do apart from diplomatically making suggestions.

Ken Ray
+2  A: 

Vital reasons to not use 3rd party software:

   - licensing
      possible high costs
      risk of rising cost later
      restrictions on use (relicensing, etc)
   - functionality limitations
   - risk of support
      inadequate solutions
      insufficiently quick

Vital reasons to use 3rd party software:

   + Access to true expert knowledge
   + known time to solution
   + possible lower costs
   + no concerns abou unknown time to completion
   + no troubles finding unavailable skill-sets
   + ongoing support needs 
      offloading / outsourcing staffing needs
      ease of finding skilled help later

Every situation is different.

All that said, I happen to hold 4 patents on GRID technologies so I know a lot about it; there are a lot of "inadequate" solutions and a really good one is more than a five year endeavour, presuming you have the right mind-set when you begin. Plenty have tried and more or less failed (though nobody likes to admit it). Even starting with Globus, it's easily three years to having something useful. MOST people who attempt it end up many years later saying that what resulted never met their original expectations - they just changed their expectations... There is only ONE "turn key" provider in this space, and they're hard to find as they've been working quietly in Earth Science...

Richard T
A: 

It won't help you with a specific individual, but fostering an environment where people look first for library code before implementing things themselves is a good long term solution. Some shops have "Not Invented Here" mindset, and in those cases you end up burning far too many cycles every time you want to bring in some outside code. Heading that off at the pass with a culture of re-use can save a lot of time.

edebill
A: 

I once was up against this decision, on a PHP system. I ended up building my own grid component, because I didn't like any of the existing ones. It's one of those projects that seems simple at first but takes on a life of its own as you start actually nailing down requirements. Really, it's a cool project, but if it's not done as a hobby, just use one of the existing ones, even if it's just a starting point for customization. You'll have a better product in less time.

The trick to convincing the guy is probably writing down requirements:

  • high-performance
  • column reordering, sorting
  • cell formatting (with custom data types)
  • row filtering, coloring, selection
  • keyboard-navigable (with modifier-based selection)
  • excel export
  • ...

Once you actually try to write down all the stuff you'll eventually expect a grid to do, it just doesn't make sense anymore to roll your own, because it's simply too much code and maintenance.

Joeri Sebrechts