EMV transactions in the iSC480

My boss’s boss was informed that the credit card laws were changing and therefore, we needed to deploy new credit card readers and change our program to interface with the new readers.

I had already gotten started with development and was interfacing with the iSC480 very well (see previous article for more details).  My one remaining task was to detect when a user was trying to “swipe” an EMV card.  The EMV card must be inserted and not swiped.

The documentation said several times, “If the swiped card is an EMV card then the cardholder will be prompted to insert the card” (Dev Guide, sec 3_6_18, variable 413).  Well, that never happened.  So I had to write that code myself.

It was pretty easy.  I just had to determine if a card is an EMV card.  Track 2 contains a service code (positions 21-24).  If position 21 contains a “2” or “6”, then the card is an EMV card and must be inserted.  I detected it and changed the screen message and I was back on track again.  No biggie.

When I inserted a EMV card, nothing happened.  The vendor said that the device should start automatically running through screens.  I never saw any of that.  Finally, my team had a phone conference with a tech guy from the vendor.  He pointed out a few VERY important pieces that were necessary to process EMV transactions:

1. EMV must be turned on in the device.  By default, it is NOT turned on.  So, you will never get anywhere until you know this critical step.  To turn on EMV in the device, you need to send a “M60” command to change setting “19” to a “1” instead of the default of “0”.  The support guy was surprised that I hadn’t read that tidbit because it was “easy to find” somewhere in the 826-page-long PDF document (Dev Guide).  I eventually found it under the section titled “Support for Voice Referral for EMV”.  I guess they figured the whole “voice referral” part would not dissuade me.  They were mistaken.

2. Once the user inserts the card, a 09 command is received (via the API). At this point, you (the programmer) needs to send the following:
– M14 (use transaction type 01 = Sale)
– M13 (Set amount, without the decimal point)
– The device will respond with a 33.02 message
– M04 (set the transaction to “B” for credit or “A” for debit, etc)
– M13 (set the amount again, for some reason)

Then, the device will take-off and do all of the EMV magic.  The user will have to do some actions on the screen.  These actions will vary, based on the settings inside of the EMV chip in the card.

3. When the user completes all of the required input, the device will send a 33.03 message asking you (the programmer/program) to do a credit auth.  You need to respond with a M22.04 message.

4. The device will ask the user to eject the card.  The device might ask the user to sign.

5. When the user is done signing, the device will not give any indication that the user is done signing.  That is of course, unless you already knew that you had to set variable “0009” to “1” and you have already done it, before you started any of this.   If you already took care of this, the device will send a “20.0” message to indicate that the signature is done. Otherwise, you could always set up a polling loop (timer thread) to check if a signature message has been recently received.

6. Done.

So, as long as you know all of these little tricks, the EMV stuff is pretty easy to deal-with in the iSC480.  Otherwise, the EMV stuff may not seem very intuitive and it will have you scratching your head for a while.
I was disappointed that, Goog/Bing didn’t have any info about it. I guess people aren’t supposed to talk about the SDK. I have been intentionally vague in this article, to avoid heat. So, if this article didn’t make any sense, it is probably because you don’t already have the SDK.

Final note: Snaps to the tech support at the vendor. I always hate calling for tech support. It feels the same as stopping at a gas station and asking for directions. *ugh*. However, in this case I wish I hadn’t burned two weeks before I called. The support folks at the vendor, got me back-on-track quickly. The phone call and solution took like, 5 minutes.

Hopefully, you found this guide on the web and it saved you a lot of headaches.

Posted in Programming | Tagged | Leave a comment

Training your manager

Disclaimer: This is not about my current workplace. This is about all workplaces.

Whether you are a team lead, software architect, PM or a junior developer, you count on your team for stuff. Maybe if you are a one-man-team, you do this to a lesser-degree, but you still would have to count on yourself to fill those roles.

Each of the roles on a team, are there because they have a function in the process of writing software. Everybody has a job to do. If every job is done well, the whole thing works like a charm.

Believe it or not, management also has a job to do. I’ve met people who honestly thought the job of management was simply to watch you work and badger you. I’ve known others who thought the job of management was to set up snares to catch you when you made a mistake and then make you pay for it. I’m inclined to think that those people just didn’t have a realistic understanding of things. Maybe they were pessimistic or obtuse, or maybe just downright paranoid.

The really good managers are always there to help and you can see the value they contribute. For example, a good manager will do the following:

  • Ask if you need anything to do your job. If you need something, they acquire it for you or help you acquire it. (within reason)
  • Attend meetings for you and handle issues, so you can focus on your work.
  • They keep you informed, so you understand the big picture and see how you are contributing to the success of your organization.
  • They plan ahead. Short term plans are very detailed. Long term plans are more vague, but become more detailed as they approach.
  • They work with you to determine solutions and estimates, and technologies.
  • They do more asking than telling.
  • They encourage you to think about how you can grow your organization and yourself.
  • They get you the recognition you deserve.

Of course, not all managers are good managers. The career goal of a manager is to make other management believe he is doing a good job. That is how you get advancement. However, this is easily confused with the higher goal, of making management believe his people are doing a good job. Note the difference “I am doing a good job (regardless of my people)” vs “My people are doing a good job (therefore, I must be doing a good job)”.

Not all managers are born with the innate ability to recognize this higher goal, but that is no reason to distress. If you find yourself in the hands of a manager who is not taking care of you, you just need to work on that person, like you work on any of your other skills. Managers can be trained, they just need to see the carrot.

If your manager has some room-for-improvement, try asking him do to the stuff that you need him to do. Help him understand how this helps you and moreover, helps him.

  • If he is not giving you recognition, try showing him how this is done. Write a weekly document that highlights a few things
    • Accomplishments for the week
    • Plans for next week
    • Roadblocks or resources that you need
  • If you deliver something really valuable (like a weekly document highlighting accomplishments) and the manager says you don’t need to do this. Tell him that you like to do this and you know of other managers who ask for this kind of thing. Therefore, you feel obliged to do this yourself. Then mention how it must make his job easier, because his manager must need this kind of info from him. He can just copy it out of your status report and send it upward.
  • Do your own monthly evaluations and invite your manager to participate. After a few of them, the manager will see the pattern and join-in.
  • Find out what other kinds of paperwork a manager should be doing. Do it for him and give it to him. He will see that it is not that hard (since you were able to do it). Also, modifying an existing document is much easier than starting from scratch.
  • Make the time to talk about progress. Don’t just talk about the current problems, talk about small solutions to the current problems. Build momentum and a “can do” attitude. Turn it into a habit.

If you’ve never done this for a manager, you might be thinking that I must be kidding. It sounds like I’m suggesting that you do your manager’s work and he will get all of the credit for it. Well, you are half right.

This kind of paperwork does of course benefit you too. Visibility is rarely a bad thing for you (unless you have something to hide). Plus, some day, you might take a vacation day/week. That is a great time to pass the baton.

Training a manager might be something you’ve never tried, but like anything, you can learn to do it well, and reap the benefits.

Posted in Career, IT Psychology, Lessons Learned, Professionalism, Team | Tagged , , | Leave a comment

Magnitudes of technical debt

The term “technical debt” really covers a lot of areas of concern. It is not simply relegated to “messy programming”. That is part of it, but there is more to it.

Like with many unpleasant things, the impact of technical debt, can be measured in magnitudes. Some kinds of technical debt are easy to deal-with and some are monumental. When a developer says “let’s resolve the technical debt around here”, be careful about writing a blank check.

Like with all development efforts, it is a good idea to “contain your scope”. You will generally maximize ROI and build momentum when you start with the low-hanging fruit and avoid items of high impact.

Low impact tech-debt (quick ROI) examples:

  • Compiler build warnings – These are usually easy to resolve. Make a habit of resolving these as they appear, or work to eliminate a dozen of these a day/week.
  • Coding conventions violations – When your code is “conventional”, it is easier to maintain. Pick a coding convention and enforce it. Then there won’t be “my code” and “your code”. It will all look identical.
  • Configs – Hard coded settings in a project can be evil. You don’t want to modify your program every time you move it to a different server or file path. That is bananas, and very risky. Make sure you have those settings in config files. Make sure the configs are clean.

Med impact tech-debt examples:

  • Obsolescence, falling behind – Don’t let your program turn into “the next COBOL”. Even if it is actually written COBOL, you can still take periodic steps to keep it updated and modern.
  • Awkward programming styles – Ninja programmers can come up with some impressive stuff, but you don’t want your code written in a manner where only a genius can maintain it. If you haven’t generously applied “the kiss principal”, then you are carrying some tech debt with a heavy burden, and it will cost you.
  • Lack of error handling – If a user complains about your buggy program and you have to ask what they did when an error occurs, then you don’t have adequate error handling. Your error handlers are metal detectors to show you the needles in the haystacks. You don’t ever want to live without them. Be generous with error handlers and logging.
  • Inadequate tracing – See error handlers, and imagine that something went bad, but didn’t result in an error that could be caught. Without a trail of breadcrumbs, it will take a frustrating amount of time to recreate the conditions. Eventually, you will wish you had tracing to tell what was happening.
  • Things like: global variables (a needle that seems to move around in your haystack)
  • DLL hell, GAC hell, SP hell, all of the other hells that come from reuse/sharing of code. – Brochureware always sells the idea of code reuse, like it is so great and never turns your life into a nightmare. If you’ve been around the block, you know better. Caveat emptor.

High impact tech-debt examples:

  • Architecture – If your architecture paints you into a corner, you might be in the worst kind of checkmate. Starting-over, might be your only hope.
  • Bad designs – There are all kinds of ways to design a system, which makes them impossible to maintain or close-enough to it. Untying some knots, can turn into epic tales.
  • Security – Thanks to the internet, security is a big enough topic that it a career path for many people. Dabbling in security is like being your own lawyer. It is not a good place to learn from your mistakes.
  • Platform (OS, data, language) – I’ve always laughed at IT people who warned you about a technology like SQL Server or .NET because “you don’t want to be locked into a single platform”. It is a ridiculous claim and the people who fall for it eventually realize that people don’t switch platforms for any good reason. If you ever do switch platforms, you will never do it twice. Locking into a platform is a way to get stability. Y’know, like a foundation. You don’t just switch it periodically.

I’m not saying you can never tackle the topics on the High list. Sometimes you just need to do those. However, don’t do it on a whim. Rome wasn’t built in a day. Don’t start with Mt Everest.

Most important of all: The time to be the most careful with these things is BEFORE you start programming and not afterwards. Like a foundation, you want to start with a solid one, in a reliable place. Make sure the big items are done correctly by someone who knows their stuff (and not just some silver-tongued sales person or giddy fan-boy).

In the words of Bertrand Russell, “Fools and fanatics are always so certain of themselves, but wiser people so full of doubts.” Measure yourself by those words.

Posted in Architecture, Lessons Learned, Review | Tagged , , | Leave a comment

LLT – M53: unknown product code (add it in ‘LLT.prm’ file)

Once again with the LLT. I just got a new PC and had to reinstall all of my software and re-learn the tricks for connecting LLT, etc.  Btw, the help file for LLT has better directions than the rest of the docs. I wasted an hour trying to figure out how to get the device into LLT mode.  Hint: read the LLT docs, section 6.  Btw. the “up” key is the minus -.

When I tried to connect LLT to my device, I was getting this connection error:

“M53: unknown product code (add it in ‘LLT.prm’ file)”

The LLT.prm file is in the same folder as your LLT.exe.  It has a list of all of the possible devices, but it stops at M52.  The iSC480 is supposed to be M53.  For some reason, in the past 2 years, nobody has managed to update this file.  *ehem*.  So we have to do it ourselves.  No biggie, I guess.

Use notepad.exe to edit the LLT.prm file.  Put “M53: iSC480” on the last line (before the line that says “M??:all products”).  Save, and re-launch LLT.  Since it probably took you five minutes to make the change, your iSC480 has probably restarted, so you need to do that trick to get back into LLT mode. 🙂

Btw, the entry for M53 is optional.  The LLT will connect to your device and work etc. even with this error.  It is really just a warning.

Posted in Errors, Lessons Learned | Tagged , | Leave a comment

LLT_LOAD – RAS Error 633

Today, I needed to upgrade the RBA for my device.  I started by using LLT to set up my connection and make sure everything worked.  I worked-out the configs and was able to get a file list in LLT.  So I was certain that everything was good to go. Configs were right.

When I ran LLT_LOAD.bat (for my device), I was getting LLT “Run-time error ’13’: Type mismatch”, then the LLT_LOAD screen gave me a red error message “!!!!ErrorCode: #### DOWNLOAD FAILED – PPP CONNECTION PROBLEM!!!!”.

The message didn’t really give any useful information, so I read the bat file, to get an idea what was going on.  It referred to a log file, which I found (relative to LLT_LOAD.bat) in ..\log\ResBatch.txt.  In the log file it said the problem was caused by RAS Error 633.  Whatever that means!  Searching Goog and Bing didn’t really help.  I put a few debug/trace statements into the bat file, to see what was going on and tried a few other things.  Eventually I guessed at the problem.

Things that were not wrong:  Device was in LLT mode, device was connected, I know I had my LLT and connection configured properly. You don’t need to run LLT_LOAD as admin.

Solution: it was a bonehead mistake on my part, but easy to make.  The prompt says

“ENTER COM PORT # or [ENTER] for COM1 :”

Since the prompt referred to the COM port using the format “COM1”, I figured it would need my answer (COM3) in the format “COM3”.  Nope.  It just needs the digit “3”.  Once I gave it just the numeric part of the COM port, everything ran like a champ.

I’m now on the new RBA.  Hope I helped you solve things too. Good luck!

Follow-up: the “LLT User Guide.pdf” does talk about RAS 633 in sec 10.3, but it just says to check if your cable is connected and that the USB plug/played.

Posted in Errors, Lessons Learned | Tagged , | Leave a comment

Why management wants more technical debt

*** Disclaimer: this is not about my current project. It is about every project. ***

I think it is safe to say that every program contains some technical debt.  This is because perfection is (somewhat) impractical.  If you actually try to achieve it, you have probably invested more time into the program than is necessary.  It is more practical to achieve “good enough” or “really good”.  Even “excellent” is an achievable goal for some programs, but “perfection”, is more than just lofty.

I’ve already talked about the costs of retaining technical debt and the consequences of accumulating too much of it. So why allow any of it in the first place?

One Man’s Treasure…

Any manager who is not deeply familiar with software development, will not be aware of the value of clean code. When you talk with management about technical debt and ask for time/budget to resolve it, you may often encounter resistance or disbelief. “How did we get technical-debt, in the first place?”. “Do you mean to tell me that the programmers are writing sloppy code?” “The program actually works now, and we are living with it, so maybe this is not really a problem. So, just leave it as-is”.

[Ignoring technical debt] could be equated to: manufacturing a new car and not painting it. Yes, the car runs and there is no rust today. Next week the rust will be minimal, but in two years, it will be falling apart and be un-drivable. It is a very difficult message to convey, and even harder (sometimes) to get management to acknowledge it.

Many teams know that resolving tech-debt, is a feature.  It may sound strange, because your users don’t see it with their eyes. However, like with any feature in a program, you can place it on your priority list, and apply more or less effort to it. You can also postpone it or completely omit it.  It all depends on how much value you choose to place on that feature.

If you choose to place a high-priority on [resolving tech-debt], you will perform reviews and enforce standards for your project:

  • Developer self-reviews and refactoring
  • Peer reviews
  • Formal code reviews
  • Architecture and system reviews
  • Quarterly and Annual upgrades to technology
  • An overall attitude of constant improvement

Of course, don’t forget the most important part of the review process: the resolution.  All of the reviewing in the world, won’t make a bit of difference if you cannot commit-to resolving the problems that are found during these reviews.  It is like seeing a house fire, and saying “someone should put-out that fire” and then walking away, without doing anything to help.

Another Man’s Trash

If you are a developer, you probably read that list of reviews and thought “I’m going to print that list and glue it to the wall in front of every manager.”
If you are a manager, you read that list and thought, “wow, that is a list of increasingly lofty goals.”
If you were a VP, you are still probably thinking “we can live without all that stuff. Cut it from scope.”

Bottom line: in general, many managers believe they add value by squeezing more efficiency out of their people and their department. Some of them cannot resist the temptation to squeeze a timeline too much. Initially, it may seem great that the work got done so quickly. Therefore, upper management may or may-not ask the right questions.

The wrong question is “how did you do it?” Because the answer will probably be “The programmers were slackers. I applied some pressure, and they stopped wasting a bunch of time on unproductive crap”. The manager is really just gaming-the-system, because the corners which were cut are usually the ones which produce a higher-quality product. The more quality you cut, the quicker things seem to get “done”. It doesn’t take much skill to do, and it usually results in some nice short-term rewards. Therefore, the incentive is very tempting.

Cutting-out “tech debt resolution” is a dangerous practice and the victims are entire organizations who are impressed by superficial results without an understanding of the problems lurking beneath and accumulating. By the time the project reaches technical bankruptcy, the ones who were responsible have usually moved-on.

In my next post, I will talk about ways to analyze your work, to assess how much debt you are carrying and the level of effort to resolve the problem.

Posted in Lessons Learned, Methodology | Tagged , , | Leave a comment

Technical debt and interest

In case you are not familiar with the term “technical debt”, it mostly means “messy programming”.  Unfortunately, it is more serious than just ordinary messiness.  It usually happens because a programmer was in a hurry and couldn’t think of a better way to make the program at-that-moment.  Later-on, other programmers will see the code and think “why was this written like that?  It would be much better if…”

Like with financial debt, there is interest. The “interest payment” for technical debt is “paid” by all of the developers who come in contact with the debt-laden code.  Everyone takes a little longer to comprehend the code, or apply a fix without breaking everything.  It slows everyone down, and this is the “interest payment”.  It may not seem like much, but it all adds up.  If the debt is big enough or continues to accumulate, eventually you could spend more time paying interest on your debt than doing actual work.

Have you ever wondered “why does it take these developers so long to complete (seemingly) simple or ordinary tasks?”  This is a pretty good indicator of the amount of technical debt in a program.  Imagine something simple that you might do, like making a PB&J sandwich, except the bread isn’t sliced and you are out of PB and J, and those are sold at different stores.  That is technical debt.  The task would take seconds if everything was arranged for your convenience and speed.

Payment plans

It sounds logical that sending a hundred dollars every month to a creditor, should pay down your debt eventually. However, that is largely dependent on your amount of debt and interest rate. If 9/10 of your payment goes to interest, then your progress is going to be low.  A double payment is going to have a much larger impact, but you might not be able to afford it.

With technical debt, once a developer has waded through a file and negotiated his way through it, he will have a better understanding of the debt itself, because he has paid the interest.  Now he can do his work (the reason he was here in the first place).  There is something more he could do right now.  Since [knowing the problem] is half the battle, he sees the technical debt (paid the interest). He could take a few minutes, or even hours to resolve the tech debt.  Once the debt is paid, the team can enjoy the lasting benefit.

Finding a balance

Of course there are two problems:
1) YMMV –  If the developer suggests that you just rewrite the whole thing, then you are less likely to get a good ROI.  You really need to have a team policy about “how good are we aiming towards”.  Don’t say “perfection” because that means something different to everyone.
2) Knowing when is a good time to fix it – Of course, it seems like a good idea to fix it as-soon-as-you-see-it, but that is not compatible with most timelines.

I’ve had good success with granting developers a budget of 2 hours per week, of tech-debt resolution time.  The time can be applied at the discretion of the developer, but still needs to be documented and tracked.  We don’t want developers getting carried away, after all.  Any tech debt that takes more than 2 hours, goes into TFS first (or other work-tracking / requirements pool) and then it gets more evaluation: consider approaches/alternatives. Management can evaluate it and prioritize it.  Just be careful to not burn up 4 hours to evaluate an issue that can be fixed in 2 hours.  Show some good judgment.

Paying down debt it achievable and the ROI can be substantial.  If you want your developers to get more work done quicker, then plan on making a few “double payments” and get some of that technical debt out of their way.

Posted in IT Psychology, Methodology | Tagged , , | Leave a comment