When I started using internet banking a few years ago, my bank sent me this small device that displayed a random six-digit number I had to enter on the website for logging in. I wondered how does this actually work; how does the bank’s server know the number displayed on this small device. My best guess was that the device communicates with the server in some wireless way. The second guess was that the random number is generated based on the current time, so the server can generate the same number at that time without having to communicate with the device. So which guess was correct?

A few days ago, I got curious about this again and did some research. It turns out that the second guess is closer to real mechanism. These security devices are more formally known as “disconnected tokens” meaning that they are not wireless devices emitting any radio / infrared waves or other frequencies. These tokens are widely used in two-factor authentication, which utilizes at least two of the following factors to prove your identity:

Knowledge Factor: Something that you know, like your password.

Possession Factor: Something that you have, like the security device.

Inherence Factor: Something that you are, like your fingerprint.

The knowledge and possession factors are employed in using these disconnected tokens with passwords. Now that you know some theoretical details, here’s how the device actually works:

When the bank sends you the device, they have programmed it with your account details (in the form of a unique number or text string), and a cryptographic algorithm to generate the random 6-digit codes. When you have to log in to the iBanking website, you press the button on the device. This gets the current time from an internal quartz clock which has been synchronized with the server. The algorithm (which is mostly a hash function) uses this time, and your account information to generate a code. Since it’s based on time, this code is valid for a limited duration, usually 30-60 seconds, after which the token display turns off and you need to press the button again to generate a new code.

In short: Current Time + Account Info + Algorithm => Code

The same process is repeated on the server when you enter this code on the website. If the code generated by server matches the code you got from your device, you have been successfully authenticated (provided you entered the correct password of course).

Some other tokens generate codes based on sequence too, depending on how many times the button has been pressed. The token is given an initial code to start with. Every time you press the button, it takes the previous code(s), runs it through the cryptographic hashing algorithm and generates a new code.

So that’s the basic description of how these tokens add an extra layer of security to your bank account’s online access. Of course, the algorithms and information used can vary from one bank to another, and the whole process can be more complicated to make it more secure. Some banks are starting to roll out new devices that have a keypad, whereby the users enter information like account numbers to generate more secure pass-codes for high-value transactions.

Imagine a train driven by a steam or diesel engine. One engine controls and directs the movement of the whole train. Now imagine an electric train or a metro. Every carriage has it’s own motors and electric supply, contributing to the speed of the whole train, every coach participating in the movement.

In the analogy above, the steam engines are like conventional leaders who keep the decision making power to themselves and the rest of the team merely follows them around. On the other hand electric trains represent a more modern style of leadership where everyone is encouraged to participate in driving the team and organization ahead.

So what is participative growth? It is a paradigm of management based on respect and engagement of the employees. It harnesses the diversity of different minds and actions, to result in better outcomes for the organization. In simpler terms, it is a way of leading people by allowing them to lead. Sounds strange, but it is an important aspect of organizational growth, especially from a managerial perspective.

Styles of Leadership for Participative Growth

The conventional way of leading is the autocratic one, whereby the leader makes all the decisions himself, and the subordinates have no say in the process. However, this does not work for participative growth, for obvious reasons. Different ways of leadership have to be explored to make this possible.

The “democratic” style, simplest form of participative leadership, transfers the responsibility of making decisions to the whole team. True to its name, this is mostly done by a voting-like procedure, giving everyone chance to choose a particular course of action. And of course, the majority wins. While this method does allow everyone to participate, and makes decision making relatively fast, it leaves no one responsible for the outcomes.

Another way of leading is the “consensus” style. Slightly different from the democratic style, this requires all members of the team to come to an agreement for the decision. Hence, more discussions and debates become necessary, which take more time and effort from everyone. Nevertheless, the decisions made in this way are one of the best as they utilize the skills and knowledge of everyone.

Lastly, there is the “collective” style, which is the one used mostly by organizations worldwide. The employees are allowed to contribute to the decision making process and have some say in it, but the power to finalize the decisions and the responsibility of its outcomes lies with the leader.

Although these styles allow a more comprehensive contribution from the team, sometimes the situation demands more urgent decisions to be made. In that case, of course, the traditional way of autocratic leadership works best.

Roadblocks to Participative Growth

Any group work is only as effective as its members are willing/able to participate. A frequent issue is that the team members tend to be quiet and submissive. Employees lack the confidence to speak up and voice out their views and opinions to higher management. While this is true to some extent, accepting this as an unchangeable fact of life merely worsens the problem. Leaders can work towards correcting this handicap.

Apart from the employees being unwilling to participate, some managers themselves do not allow enough participation in their teams. A major reason is that they think they must portray the image of a tough and independent leader who can make decisions without the help of his subordinates. To be seen as an effective manager and not to appear weak, they try not to involve them in the process or ask their opinion. Some just feel good by being in control, having the power to run the organization in the ways they like and perceive best.

While analysing these behaviours and attitudes of the leaders and followers alike, it becomes crucial to step back and realise that the problem lies in the organizational culture. In most traditional and hierarchical structures, the employees expect their managers to make decisions and the managers expect the employees to follow them.

Finally, time constraints can also be a factor preventing leaders from consulting their teams, as it takes time and effort from both the parties.

General Approach to Promote Participative Growth

Understanding the issues hindering participative growth, allows us to devise a better approach to promote it in our teams. Let me elaborate on the various ways in which a leader can let his team be more involved and yet be in control of the process.

It is very important to set the right expectations, right from the start. Whenever you are assigned to oversee a new project or team, or a new member joins your existing group, make sure that everyone understands what how they are supposed to do work with you and not under you. It is essential to to tell them how their success and performance will be measured, not just by following orders but also by providing their ideas and criticism. The sort of behaviours and approaches necessary for participative growth must be clearly communicated to the team.

In order to enable everyone to participate, you must also make them realize the big picture. They should understand why their section and team are doing what they do, and how does it all fit in the goals of the unit as a whole. By having a clear idea of how their actions contribute to the success of the organization, and also what are the implications of their under-performance, employees start to feel more motivated to contribute. They develop a sense of belonging and responsibility.

After this, create an environment that encourages participation from everyone. Build an atmosphere of mutual respect, shared responsibility and trust. More importantly, be friendly with your employees and make them feel at ease while talking to you. Don’t worry, this doesn’t make you look weak, only makes you more approachable. Opening up channels of communication and being honest with the team will go a long way in changing everyone’s attitude towards work.

Now comes the real part, the participation itself. Involve your team in making decisions. This is where you need to choose from the 3 styles of participative leadership. While the “collective” style serves well in most situations, go with the “democratic” for making small decisions and the “consensus” style for more important long-term decisions that deserve more thinking and planning.

Conclusion

Participative growth constructively focuses energy from everyone involved for the betterment of the whole organization. It deepens individual and collective learning, resulting in real development. While this more sustainable and empowering form of growth has its challenges, with a little effort and planning it can be made possible.

Recently I came across a bunch of server side code, implemented in the form of Perl scripts and modules – about a hundred of them. Many of them are a few thousand lines long, and they interact with each other in complex ways.

In order to understand how this system works, I had to figure out the program flow. This was difficult especially because it was not easy to reproduce the input, and I didn’t even know where to start. I decided to take the primitive but effective debugging approach of adding print statements for tracing the flow of execution. Trace statements, as they are formally called, are easier to add in smaller programs though.

In order to automate this process of adding trace statements, I tried 3 ways, one after the other:

Parsing with regular expressions: The first and most crude approach was to modify all these scripts, by parsing them, finding subroutine definitions, and adding a print statement right after the beginning of each. However, a lot of cases were overlooked while writing the regular expression, and it ended up matching the word “sub” in strings and comments and the result was disastrous. The code base was ruined beyond hope for manual repair, but of course I had backups on my own machine and also on a repository.

PPI Module: After some research I found a Perl module to parse Perl code. PPI, originally an acronym for Parse::Perl::Isolated, parses Perl code as documents, breaking it down in tokens in a strict hierarchical fashion. More details here. Using this, the task of finding subroutine definitions was simplified and made more reliable. PPI::Document -> find(‘PPI::Statement::Sub’) was all that was needed. Then, finding all the ‘children’ of each sub, and looking for PPI::Structure::Block (by checking their refs) got the beginning of each sub.

Hook::LexWrap Module: If you only want to add a trace statement (or any piece of code) at the beginning / end of a subroutine, Hook::LexWrap is a much cleaner way to do this. It doesn’t need you to change the original subroutines in any way. Just adding a few lines of code at the start of each file will suffice. In the following code, @all_subs is the array containing the names of all subroutines in the current file. The “wrap $sub, pre =>”line pre-wraps a subroutine, i.e. executes a piece of code just before the subroutine is executed.

Problem: There are towers of varying heights that need to be placed next to each other in a line, such that if any of them falls, it doesn’t topple the neighboring towers. Find the arrangement that ensures least total space between the towers.

Solving this problem by brute force requires that we find out all the possible arrangements of the towers, find the space taken in each arrangement and keep updating the minimum value after each arrangement. This seemingly simple task turned out to be very harsh on both memory and space at first. I tried to implement a slightly modified version of Johnson-Trotter algorithm. Basically, in this algorithm you start from one element and place the second element in all possible positions with respect to the first one, which would be on its left and right. The third element is then placed in all possible positions in both the permutations obtained in the previous step. That’s 3 positions for each permutation, giving us 6 permutations. And so on. Notice that after placing the nth element, you will have n! permutations.

However this algorithm is very inefficient if the purpose is just to compute all permutations in any order. Firstly, it needs all the permutations after n elements to be stored in the memory, for placing the (n+1)th element. Thus, the space complexity = O(n!). At n=15 and each element being a byte, this will require almost 18 terabytes of space. Furthermore, at every stage it requires n! steps, placing the nth element in all possible positions in the permutations calculated so far. In big-O notation this gives a time complexity of O(n!), but the actual number of steps taken will be 1! + 2! + 3! + .. + n!

The space is a big issue here, and the Java implementation of this algorithm fails if n is larger than a certain value (9 on my computer) as it runs out of memory to hold all the permutations: “Exception in thread “main” java.lang.OutOfMemoryError: Java heap space”. One way to save on the space would be to adopt a depth first approach rather than a breadth first. A picture says a thousand words, so here’s another:

This algorithm would need at most 4n space at any time (4n whenever it’s inserting the last element, because of the recursive nature). The steps taken increase in this case though. To get every permutation, you need n steps, inserting one element at a time, and hence a total of n * n! steps are needed. However, the actual code takes shorter time to run than the previous algorithm, probably because there isn’t any large amount of data that needs to be maintained and updated.

We have board games at the office every week, and the colleague who organizes them sends out weekly emails to know what kind of games we would like to play. To everyone’s amusement, this week (for the 50th session) he decided to cipher the game types in the email. Challenge to the office: decipher them!

YNQJ UQFHJRJSY
INHJ WTQQNSL

I was clueless at first, it was very difficult to find any patterns whatsoever. But then I thought of the simplest ciphers of all: substitution ciphers, where each alphabet is replaced by another fixed alphabet. The most common letter in the English language is E. So I looked for the most frequent letter in the cipher, which happened to be J or Q. So either J = E or Q = E (probably; this is just an informed guess).

But where do I go from there. How about the other letters. Applying the frequency rule didn’t seem to provide any real English words.

Enters Julius Caesar, with his own way of private correspondence. Over 2000 years ago, he used this simple ciphering technique to convey secret messages. He substituted the letters with those that come after a certain number of letters in the alphabetical sequence. Basically he shifted the letters by a fixed number. So if the shift was 3, ROME became URPH.

Applying this rule to cipher, and the guessed value of J, the shift can be guessed too. J = E => shift = J – E = 5. Shift all the letters in the cipher back by 5 positions and voila! Cracked.

Today one of my friends in the US was surprised to find out that India has had nuclear weapons since the 70s. It made me think how many countries, especially the NPT (Nuclear Non-Proliferation Treaty) signatories, frown upon India having an active nuclear weapons programme. I don’t support wars or nuclear armament in any way, but here are some of my thoughts on this issue:

India has never used its nuclear weapons, unlike the US, who has had them since the 40s. The tests have always been for peaceful purposes and to strengthen the country’s self-defense.

India’s reason for not signing NPT is that it is in many ways a neo-colonial regime designed to deny security to post-colonial powers.

US, UK, France, Russia and China still possess larger stockpiles of nuclear weapons with global range. India has smaller ones with regional range. (E.g. US has about 8000 warheads, whereas India has about 80)

CTBT (Comprehensive Nuclear-Test-Ban Treaty) has been signed and/or ratified by many countries around the world. But it is still not in force as 44 nations in its Annex2 are yet to ratify it. In 1998 India said it would only sign the treaty if the United States presented a schedule for eliminating its nuclear stockpile, a condition the United States rejected. In my opinion that was a fair condition, to maintain a balance of power in the world.

Consider the algorithmic problem of checking if a pair of given strings are anagrams of each other, without using any extra data structures or sorting. Those are the two very obvious solutions. Sort the letters and compare in sequence, or iterate over unsorted letters and keep adding them in a key-value hash. If the values are the same for both strings, we have got anagrams.

So how do we deal with this without sorting or extra data structures? The next thought that comes to mind is assigning a value to each letter and summing up all the characters in each string and comparing the sums. However assigning any random values, or sequential values like A=1, B=2 will not work. That’s because, in this scheme, different sets of letters can have the same sums. E.g. A+D = 5 and B+C = 5 too.

This brings us to assigning exponential values to characters. In this scheme, we choose a positive integer as the base B, and assign each character with values that are exponents of B. E.g. A = b1, B=b2, C=b3 and so on. Now we have to prove that different set of characters won’t produce the same sum of values. If you have any ideas on how to prove it, or how to solve this problem in some other way, please add a comment.

So I have wanted to start my own blog for a long time. Many years ago, I made one on Blogspot (now known as Blogger) and another on WordPress. But they never got too far. This time I want it to be different.