I confess: I’m a poacher turned gamekeeper. For those of you not familiar with this rather English idiom, it means that I was once the perp, but now I’m the cop.
In my formative years, when I was keen to impress any way I could, solutions to problems would just spring from any coding language I thought appropriate at the time. I’ve probably left thousands of lines of Shell, Java, Perl and PHP script in my wake, with nary a care for future support or development.
Often, when we coders are in a tight corner or perhaps not familiar with current trends or available tools, the temptation to write our own solution is compelling. We say, “I have knowledge of the problem” and “I have the skills.” What we may not have is a view to where our solution may go, the pressures that will be brought to bear on us and the solution in the future, and the fate of others who have to sail in our wake.
For me, the epiphany was an integration I wrote to solve a problem between two systems that would not normally be connected. Neither vendor had considered integrating with the other, and there was no out-of-the-box solution. That was great for me: eight weeks of playing with code was a joy, and I completed the job to specification.
Returning six months later to resolve a problem, I noticed significant changes to the code base. What had happened in the meantime was twofold. First, unanticipated new features had been added; second, these new features had been added by other coders. The result was something of a mess: My once elegant solution had become not only an organically grown mess but also a support nightmare, hard to extend and creaking at the seams.
In a more controlled development environment, these support and extensibility factors would have been addressed from the start and delivered as an agile code stream that could be useful for years to come. In a less controlled environment, that usually doesn’t happen.
These days, I’m inclined to block this kind of quick coding customisation activity unless I’m convinced there’s no other solution and that the customisation will not require huge future development or excessive support. Another criterion for success is that the customisation must be very well documented and understood by future parties—and that usually means it has to be simple.
I recognise that it’s not always possible to meet these criteria—sometimes you just need to automate or glue things together, and that often requires some sophisticated code. Products don’t always go in the direction you need them to, and sometimes specific local requirements need a solution outside of the vendor product’s capability.
So what’s the answer? Well, CA Automic (and CA IT PAM before it), enables programmers’ flair for creativity, letting us solve problems ourselves whilst providing a controlled and supportable environment with tools that accelerate development, add security and enable logging. These tools offer much more than just point integration or simple orchestration solutions. They should form the backbone of an environment and be the first port of call when we seek to automate or integrate.
My advice is this: To let your creativity be burden free and build supportable solutions for the future with confidence, set yourself up for success by using the right tools.
Happy coding!