Shelfware, Deadlines, Trials and the Pursuit of Better Coding

“Why can’t my developers just download the trial RDi, learn it and use it during the evaluation period?”  This is a question I am often asked at conferences by IT managers.   I hear their frustration.  In the spirit of fair play, I have also listened to developers on this same topic.   Here is a fictitious yet very real conversation I imagine is going on in some shops.   I will weigh in with my own opinions in a future blog.

CIO – Why can’t you just download RDi already and test it during the evaluation period?  Surely you’re given ample time to understand how it will be useful in the shop.   If you can’t find time to commit to using it during the trial period then you will never find the time.  All of the other products we’ve trialed have been validated during the same amount of time with much confidence and success.

Developer – There is a distinction between a product and a development tool.  A product, with its trial period, either works or it doesn’t.   Its functional utility becomes obvious, or not.

With RDi, it’s not just a source code editor but an entire paradigm shift.   And it’s not a product where one can “set it and forget it.”   The adoption of a new development tool takes time, and that “slows me down” when I have pressing issues to deal with.

CIO – That argument holds true only in the short term.   RDi is so much more than a simple editor.  With all of the other views that enhance productivity, you’ll be coding faster – and better – in short order.

Developer – I have everything I need in SEU et al.  There is nothing you can do in RDi that I can’t do in PDM and SEU.  If you are so sure that RDi is that much better then buy it so I can use it when I have time.

CIO – No you can’t.  How big of a list do I need to create to show you how using RDi is light years ahead?  For starters, there’s no way you’re using any of the new functionality in RPG since SEU is stable at 6.1.  This means no fully free form for starters.  So many new built-in functions.  On-exit processing for procedures.   And that’s only the start. This means you’re writing new programs using old techniques.   Techniques that will remain in our production systems for years to come and cost us more with increasing technical debt.   Also, I refuse to spend money on a software tool that’s going to simply collect dust sitting on a shelf somewhere.   Show me you’re using it and I will happily pay for it.

Developer – Then I need more time.  Don’t forget, I need to learn not only LPEX but how to navigate in a new Rational IDE.  This takes time.  Far more than what is being offered because there’s no way I’m going to use this full time each day. You would never allow me to do this because my productivity would drop, and I wouldn’t be able to put out all of the fires.   I can commit to no more than a couple of hours each day.

CIO– That may be true in the beginning, but I’ll bet after the first week of two you will be spending more and more time in RDi for everyday tasks.   RDi offers features like filtering the view of the source, code refactoring, headless code coverage for enhanced testing, wizards to create procedures and D specs, RPG code templates, content assist.  The list goes on and on.

Developer – Then give me four months.  Or better yet, six. Maybe even a year.  I need to slowly assimilate.  That’s the only way I can wrap my head around this entire tool.   And that’s also the only way I can still maintain my current workload and provide solutions to this company.

CIO AND Developer, both throwing their hands in the air – You’ll never understand.