How do we get coders to look up existing functions before writing their own?

Question

Why are so many people still writing crappy versions of things in standard libraries? Not to go after PHP developers, but guys go read the PHP SPL

Answer 1

Peer review can help catch that kind of thing. If you have another developer looking at the code, and they continually find implementations of standard library methods, it should fail the review unless there's a good reason for reinventing the wheel.

Answer 2

Better search techniques. and Domain Specific Familiarity

How does a developer check for a function they dont know the name of? Or perhaps there isnt an EXACT built in function to do what they want, but something they can use to save a lot of code. You need to be able to find the right terminology for the problem at hand, and from there you know what to search for. This is best achived by reading topics specific to your problem domain. Get away from coding specific resources and spend sometime in the field which you are coding for... wether it be retail, medical, insurance, etc.

Answer 3

Young, ambitious programmers like to solve every problem on their own. They don't need no stinkin' libraries. Older, lazy programmers would rather search for existing solutions to the problem at hand.

So my advice: the next time you hire a programmer, choose the old guy who falls asleep in the reception area.

Just kidding, mostly. Peer review and education is the answer.

Answer 4

A simple coding style document might help by reminding the devs that there are libraries available (maybe list some preferred) and that they should be familiar with them.

Sometimes, you just have to remind people.

A peer review would help.

Answer 5

Summary: Assumption is the mother of all FUBARs

I see this a lot from colleagues who are unfamiliar with the concept of frameworks (god how they complain about "two languages in one"), to wit: old C++ guys suddenly confronted with C# diving in head first to recreate hashtables from scratch...

Clearly a big part of this phenomenon from that angle is not stepping out of old mindsets and habits. If you're in a new environment you need to learn the new rules. The only way to deal with that from the outside looking in is to provide training, whether that's pair-programming for a while or something more formal.

Lack of familiarity with your tools breeds the contempt of others.

Answer 6

Very hard question to answer. Obviously peer review helps, but also proper documentation. Do your projects have technical specs, where you map out the classes and intefaces to be created?

If so, someone else on the team should review the specs and point out where existing code could be used...

Answer 7

PHP is well documented if and only if, you know exactly what you're looking for. For example, you'd open Arrays and Array functions sections to see what you can do with arrays. And guess what, there is not even mention of SPL.

Answer 8

Two reasons pop to mind quickly. First, the Standard PHP Library isn't WELL known, and suffers from poor documentation. The php.net website is widely considered the language's best asset, but a lot of the newer built in classes (such as the SPL, reflection API, DomDocument, etc.) are little more than a list of methods without a lot of context.

More importantly though, it looks like the full SPL never shipped by default with any version of PHP prior to the (unreleased) 5.3. This is a killer as far as adoption goes. Usually people writing PHP code don't have control over what gets complied into their PHP binary. That's handled by their web-host and/or operations team, and web hosts and/or operations teams have different goals than a developer and aren't going to install every optional extension that comes along. This also means projects like Drupal, Joomla, Wordpress, etc. can't rely on the SPL being installed everywhere, so they don't use it.

Part of the reason PHP "won out" over perl was a single install had everything you ever needed. Optional extensions have never become widely adopted until they became part of the base install.

Answer 9

Agree with training and peer review, but also enforcing unit testing and code documentation should help with the NIH syndrome :)

Answer 10

You should also encourage research before actually setting out on writing code. I usually approach problems by thinking about a way to do it, then I try to find anything in the standard library or any other libraries that will help me out. I'd say that an hour of research in some cases can be worth days of coding.

If people aren't doing this, it may be a good idea to have someone ask them questions about their general approach to the problem and what library functions/classes they are thinking about using. If they're missing something obvious, suggest it to them.