0

I have a project which requires some complicated components built. Some of these components are promised by some obscure software packages which are proving to be poorly documented and difficult to configure and use.

I am wondering where other people draw the line during their software research phase in deciding whether to build their own packages or sticking with trying the existing packages?

And what percentage of the total project time should I spend on this kind of research?

Thanks in advance, Alex

Genadinik
  • 18,153
  • 63
  • 185
  • 284

4 Answers4

2

Ask yourself which is likely to take longer, hammering the components to fit your needs or writing your own.

Personally I pretty much always use solid, comprehensive libraries (jQuery for web development, DevExpress for WinForms) and fill in the gaps with my own code.

The only exception I remember off the top of my head was a tooltip plugin for a web application. I tried like 3, wasting hours and hours adapting each of them to my needs, even modifying their source code, playing with their images, fixing obscure css tags that baffle ie7 (cause ie8 defaults in ie7 mode on the intranet), but never quite getting it right, then just gave up and rolled my own in half an hour.

Not to say there aren't plenty of good components out there that are flexible enough to be used in active development environments, but you're unlikely to find them in the heat of developing your stuff with deadlines looming overhead. Use your free-ish time to look for them and bookmark them, try them out in a few toy projects and see how they work, so the next time you need something like them you know what to use.

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • I see what you are saying about only using the mature packages. It is hard for me to come up with a clear answer on which will take longer. I might introduce my own bugs, but I'll definitely be able to more rapidly iterate on it. – Genadinik Apr 01 '11 at 00:46
  • 2
    @Genadinik, if you really have no idea of the component and it's not widely used that you can easily see some honest reviews on the internet, chances are it's not worth it. It's at least a red flag that should prompt you into seriously looking through their documentation for some basic tasks. – Blindy Apr 01 '11 at 00:48
1

If you have to fix some minor bugs or otherwise have to observe some patterns the code doesn't currently take into account, consider contributing back into the code base as a good citizen.

If you find yourself having to substantially recode some pre-provided code to get it to work, then maybe the fact it was already "coded" is irrelevant. Bite down and chew.

If it's bologna and you need to reinvent the "wheel", consider that you've got a job that may not be compensating it's actual value.

Jared Farrish
  • 48,585
  • 17
  • 95
  • 104
1

I usually draw the line at about 1/10. Meaning if it has already taken me, say, 1 day and I still haven't gotten the off-the-shelf thing working and it would only take me 10 days to do it myself, I do it myself.

Even when it takes a little longer, it's often better in the long run to avoid the complicated, hard-to-use thing. Or, at the very least, I get a better idea of what I really need and I can pick an off-the-shelf package with my eyes wider open.

drysdam
  • 8,341
  • 1
  • 20
  • 23
1

Well i think it all depends.

Given that, it is possible for you to spend more time than u would have used for development at trying to configure and understand. I would say if you are good enough to create faster than learn the improperly documented on then go for it.

Else if the existing promises great features and will not take too much of the entire project time then go for it. Often it is very difficult to draw then line. It all depends on the situation at hand. Also you could look for alternatives to what u have now.

deVIAntCoDE
  • 64
  • 9