Full title "Why do so many companies reinvent well-known CPAN modules badly and end up writing far too much code?

1. Why do so many companies reinvent well-known CPAN modules badly and end up writing far too much code?

2. I'm a freelancer

3. I work with many different companies

4. Ten years Sixteen companies

5. A LOT of code

6. In many cases it's like they've never heard of CPAN

7. CPAN is good

8. CPAN is Perl's killer app

9. Modern Perl programming is (often) just plumbing CPAN modules together

10. Less code is good

11. Less code that you don't have to maintain is better

12. Well-tested code is good

13. Code that is tested by hundreds of people on dozens of operating systems is better

14. Why would you ignore all that ready-written, pre-tested code?

15. Hold that thought

16. Is it really that bad?

17. A straw poll

18. Who doesn't use DateTime?

19. Who doesn't use DBIx::Class?

20. Who doesn't use Template Toolkit?

21. We are not typical Perl users

22. We read use.perl

23. We read The Perl Review

24. We go to Perl Monger meetings

25. We go to Perl Conferences

26. The average Perl programmer knows less about CPAN than we do

27. They aren't bad programmers

28. They just don't follow the Perl world as closely as we do

29. Perhaps their job involves using many different languages

30. Perhaps they have better things to do with their time than reading everything on use.perl

31. Perhaps they have a life

32. To return to our question

33. Why would you ignore all that ready-written, pre-tested code?

34. Reason 1: People don't know what is on CPAN

35. Reason 2: People don't know what is good on CPAN

36. Not everyone knows how to extract the jewels from the crap on CPAN

37. The Perl Echo Chamber strikes again

38. Be the CPAN expert in your company

39. Offer training sessions on CPAN modules

40. Draw your colleagues into the echo chamber

41. Resistance is futile

42. Reason 3: Not Invented Here

43. Some companies prefer their own code over CPAN code

44. “ CPAN code is unsupported”

45. Reason 4: Legacy Code

46. Newer modules didn't exist when code was written

47. Fair enough (of course)

48. But use the modern modules in new development

49. Refactor when you have the chance

50. Reason 5: Older versions of required modules

51. Can't install DBIx::Class because DBD::mysql is three years out of date

52. Fear of updating key modules

53. Refresh your installed modules regularly

54. You do have a trustworthy testing environment I assume

55. (Tell management that the older versions are no longer supported)

56. Reason 6: Sysadmins

57. Some sysadmins don't like to install modules from CPAN

58. They prefer their operating system's own packaging system (deb, rpm, etc)

59. Find a repository that packages CPAN modules for your operating system

60. Learn to package CPAN modules for your operating system

61. Also Sysadmins like beer

62. Some vague and ill thought out conclusions

63. CPAN is good

64. Use of well-chosen CPAN modules can dramatically cut the amount of code you need to write

65. Use of well-chosen CPAN modules can dramatically cut the amount of code you need to write

66. Use of CPAN modules cut the code you write

67. Write less code

68. CPAN code will be better tested than your own code

69. Everyone needs help finding the good stuff on CPAN

70. Evangelise CPAN at your company

71. (I find DateTime is a good starting point)

72. Mention CPAN when talking about successes with management

73. Your sysadmin is your friend

74. (and often a good drinking partner)

75. Invite me to laugh at (and improve) your codebase

76. Dave Cross Magnum Solutions [email_address] http://mag-sol.com