in reply to Advice on best practices
Most of the issues you raise are language agnostic and boil down to: "don't repeat yourself", "don't reinvent the wheel" and "use the power of the force" (well, that one I just invented to encapsulate "don't shell out if you don't have to" in a sexier package).
Perl and its environment provide much better ways of handling all the issues you mention and adopting the solutions you suggest would result in more robust and easier to maintain code. However this doesn't sound like a coding issue to me. It sounds like a culture or personality issue. I suspect the other consultant is not lazy enough to do the work up front that would ensure robust, reliable and maintainable code and it may be hard to reprogram that consultant appropriately. You need a way to convey the virtue of laziness, and that being lazy means doing the required work so you don't have to redo it.
Some of the required work may be learning to use the tools available to best advantage and that very likely requires learning new stuff. Many people will willing crawl over fields of broken glass to avoid having to learn new stuff.
Your choice is between just going with the flow and introducing minor clean ups as you can without disrupting the project, or finding a way to reprogram the consultant in a short enough time to be useful and still get the project done on time. Someone is going to suffer regardless!
|
|---|