smiller

I work with a small team (in a large company) to maintain a widely used and system critical test automation framework developed in-house. This framework was developed when perl 5.6 was considering cutting-edge, and the archaic techniques of the C programmers who designed the system are readily apparently. As an ardent supporter of Modern Perl this frustrates me on a daily basis.

This framework, and the tests written to use it, encompass nearly 2.5 million lines of code. Because of the horrendous design of the framework, I would imagine that at least a million lines of that (and probably more) is boilerplate. The organization places on on this code and any efforts made to actually improve the sad state of affairs, are almost always rebuffed.

Sure I can pick away at little things around the edges...convince people to 'use base' for importing Exporter, or make sure 'use strict' is used framework wide. I can improve specific, heavily-used subroutines for maintainability, style, and speed. I can even write up complete internal style guides...which nobody will read, because they'll just find a similar piece of code from a poorly written module and copy/paste. Doing these things often feels Sisyphean.

So how does one really make a difference in bringing an archaic codebase up to modern standards in a relatively uninterested working environment? Well here are the challenges I have identified for my situation:

1. Distribution - Currently our automated testing product is distributed to the organization by way of tarballs. Whenever we deem it time to create a new package, we essentially take a snapshot of our CVS repo (don't get be started), do some rudimentary testing, tar it up, and put it out for download. This leads to two things 1) we are discouraged from using external CPAN modules since everything our framework does should either be packaged in the tarball or available in standard perl, and 2) whenever even the smallest thing gets changed, a brand new package needs to be deployed in order get it out to our userbase.
2. NIH - Leading from our Distribution woes, our group has an extraordinarily strong Not Invented Here attitude. This leads to all the things you'd expect. Constantly re-inventing the wheel, adding additional things to test/maintain/support while also increasing (probably) weaker code into our codebase.
3. Easy To Do Wrong Things - One of the things I've learned from working with great, well-designed perl frameworks like Moose or Catalyst, is that the most important thing a framework can do is make it easy to do things the right way, and make it hard to do things the wrong way. For my money, making it hard to do things the wrong way is the harder of the two tasks, and also the most important. Our framework has made it extraordinarily easy to do things in ways that make our lives hell, and yet nobody seems willing to correct these things because then we'd break the code of people doing things incorrectly.
4. Boilerplate - As I mentioned, there is an awful lot of boilerplate in our codebase. Instead of designing a system that would make it easy for people to perform routine and common tasks, our framework forces you to do every little thing every time. There is modularity, but only to a certain level and adding an addition level of abstraction to the mix is always a pain.
5. Ease-of-Use - And finally, probably the worst part of working with an archaic codebase is the complete lack of attention to the ease-of-use factor. In a project like this one, there was so much effort being put into just getting it working at all, that ease-of-use for longterm use and maintainability was never even a consideration. 2.5 million lines of code later, we're paying the price.

So, as someone who cares about the quality of the perl code I work with, I have my hands full. I'm gonna try to keep writing about my struggles with an old perl framework stuck behind the DarkPAN, and hopefully it'll be interesting.