Why do so many companies ...

  • 1,983 views
Uploaded on

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

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,983
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
24
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 77.