We went live on another jPOS-based application last Friday morning. That alone is not news, as jPOS has proven itself to be production-worthy in a multitude of operating environments in settings across the world. What is news is that we went live on a release based upon our internal SVN revision r1008. Now, we tend to iterate in small chunks, and we also update our internal documentation within the same framework. But, still: Alejandro and I felt that crossing r1000 threshold was very emblematic of our complex, time-consuming, detail-laden project. It was one that took a lot of time and effort to get right. Many people don't want to hear this, but in the world of OLTP Payment Processing where we live, iteration, continuous improvement and sufficient time to get the details right are prerequisites to getting a quality release. Reversal matchups, third-party certifications, proprietary terminal message formats, esoteric card encryption schemes, PA-DSS compliance, Triple DES nuances, processors that have never done Debit/EBT before but pretend otherwise...all these factors ADD UP.
With that as background (and the reality), there are two irritating, grating trends to comment on:
- jPOS list members who write these e-mails that say (in essence) "Hurry up with your answer because my deadline is next week." Sorry, you just lost the respect of every member of the list when you send an e-mail like that. As best expressed by Matias' recent answer to one of these posts: "Yes yes yes now lets all stop doing what our work demands us to do in order to fully implement your solution because you are in a hurry. Oh, wait, no, that is not how it is done." Sorry, but when you post an e-mail that shows a lack of understanding of payment systems projects, you deserve a response like Matias'. In terms of your crazy deadline, either you made a ridiculous promise to your boss, or your boss imposed a ridiculous deadline on you and you didn't have the depth and guts to push back and call it unreasonable. Either way, the jPOS list members should not shoulder the burdens of your professional shortcomings.
- Customers who say "when this goes into production it better be right, because you can't change it." This really isn't worth commenting on in-depth, except to say that these are people who don't understand software projects. You can test and test and test and certify and get official signoff and everything, but the fact of life is that you will see some different behaviors in production that will require adjustments. And, in the spirit of continuous improvement, you will always see ways to do things better. The project manager who gives up on iterative improvement because of fear of a new release is not doing their job. You simply cannot give up the iterative and incremental nature of progress just because you've gone live. Some of customers cringe or openly disagree when I use the word 'iterative,' but that's the way it is in these payment processing worlds.
Recent Comments