Adherence conceptually is (number of actual occurrences)/(expected number of occurrences) of any event. The event can be visiting the clinic on a specific date, taking a dose on time etc. Though conceptually very simple, adherence proved to be a quite complex data to model.

Adherence is continuous in nature. The adherence to a dosage for example depends upon data recorded from the time a patient was enrolled into the dosage. Let us assume that the patient has to take a dose every day according to the dosage, then adherence on fifth day is (number of doses patient has actually taken over five days) / 5.

A simple implementation is to record total number of doses taken, persist the information. Then when adherence is necessary, read the number of doses taken from the db, figure out the number of doses he is supposed to take from dosage information and calculate the adherence. There were some very serious implications when this model was followed.

For one, let us assume that the system is down for some time. Then the patient could not record the adherence. But still, the system would assume that the patient has not taken the doses and there by, adherence would decrease without any fault from the patient’s side. This combined with the fact that, adherence on specific dates in the past was a point of interest, we could not go ahead with this model.

Then we decided to record the information whether the dose was taken each day. Though this did not ensure that the adherence would not decrease when the system is down, we could calculate the adherence on any given date. This was a major plus.

We still had to solve the problem that, when the system if down, adherence percentage should not decrease. To over come this problem, we decided to create a log whether the dose is taken or not taken. In which case, adherence would be the number of (taken logs)/total no of logs. When the system is down, logs would not be created, and thus adherence percentage can be maintined.

Following the above model, severly restricted the system in a different way. For the model to work, it is necessary that each log should record the adherence information of one and only one dose. If the log recorded adherence for more than one dose, the date when each dose was taken, would have to be stored in a clumsy way. This does not bode well since the the queries on the model are date based.

The above restrictoion combined with the fact that adherence had to be captured on daily as well as a weekly basis, with the requirement that the switch from daily to weekly should be consistent, forced to look at a completely different way to model adherence

    For one, I decide to write a twitter client using adobe air just for the fun of it. I spent so much time figuring out what the application should do, I created off a repository in github and eventually, did not manage to check in a single line of code.

    There are certain myths about thinking through what you have to do, that need to be broken. For one, you can never think about or reason about something that you have no idea about. Of course, you would have some idea about programming, and I presume, that is the reason why you are reading this post. But back to the point, even though you have a sound understanding on programming, it is very difficult to come up with a structure for the program you have to write NOW. This is because each program is unique in itself, though there might exist some commonality.

    To overcome traps such as these, I find it useful to create some concrete artifacts that give you an idea of how to proceed. The following are some artifacts that I find to be really useful. I call them feedback generators.

Code : Nothing provides so much clarity than the first line of code that you write.

Unit test : Feel like code is in the wrong place? write off a unit test. You need to set up a lot of variables before you can get to the assertion? you have written the code in the wrong class.

Comment: Though code is the most rigorous and most helpful artifact, I sometimes find that enumerating a set of tasks as comments is quite helpful.

Hypothesis: I have found it to be really useful in pin-pointing the source of a defect. If it is correct, gotcha!!!, incorrect? probably you would have a better understanding of the defect by the time you found hypothesis 1 to be wrong.

The Dumbest solution: I have in some cases found it useful, to think about something that is so obviously wrong, but it eventually leads to a better solution.

Similar solution:  Solutions to similar problems are tremendously helpful resources.

Wish list: When writing a program, we create data structures. When writing algorithms around those data-structures, it is tremendously useful to create a wish list of information that you would have liked the data structure to have to make your life easier.

Some artifacts, that I have found to be tremendously wasteful.

Writing down and mind maps: These just reflect what you think, and never have helped me to figure out the solution to a problem or in writing a program.

The counter example: When I am writing a program or solving a problem, I try to find a failure case as soon as possible. The disadvantage of this is that, I don’t see the few things that I am doing correct, and end up back in square 1.

Meta physical questions: Like should the Person know about a test. Nothing is as wasteful as this. If you end up in this discussion, write off some tests that consume the information and see if it should or should not have a reference. Also I have found normalization to be a good technique to answer these kind of questions.

    The important thing to remember when using feedback generators, is that, one should start reasoning based on them, once they are created. If one goes off into a tangential line of reason, the feedback generator will be ineffective, and would have eaten up precious time.

I am trying  to apply these feedback generators in earnest whenever I write code. I will post back, with updates on how well I fare.

Quote for the Day,

“If you want to survive here, have an opinion” – House

Each sentence in a good essay, makes sense in its own rite. But at the same time, it maintains an un-interrupted flow between the sentences before and after it.  The same is true for a paragraph. Each expression in code must make sense in its own rite, at the same time it should maintain an un-interrupted flow between the expressions before and after it.

Each paragraph in an essay describes one and only one concept. Each method in a good code does the same. A paragraph, that adds a snide comment on another concept described elsewhere is a pain to read. The same is true for a method. Conversely, each concept is described in a set of consecutive paragraphs. Similarly, each concept in code is described in an object.

Good essay and good code, they both flow. Neither throws stuff at the reader which he/she does not understand. If they are trying to describe a concept that the reader does not understand yet, they do so gradually, showing the reader every link in the chain from the understood to the less understood.

Quote for the day,

“Programming is understanding” - Bjarne Stroustrup.

I for one, have observed that formal education in 9 cases out of 10, transforms the lives of people. It is my belief therefore, that formal education is necessary. But the fact is, Initially, I found it very hard to apply whatever I learnt at college to the job at hand. But slowly, I began to realize, that it is what I took out of my schooling, that made it impossible to use what I have learnt.

In my high school, education was a very simple equation. X number of lines you remember, your marks increase by a factor of X. X number of formulas you remember, X number of problems you can solve and again your marks increase by a factor of X. X number of problems on linear equations you practice, your mark increases by a factor of X.

This approach made college very difficult for me. I still remember the first C programming exam that I took. The problem was a simple one, something that had to do with finding the minimum of three alphabets which are the keys to three columns in a 2-d array and print out the columns in corresponding order. I sat there mortified. It did not make sense. I knew the algorithm to find minimum of a list perfectly well. It was there in my observation notebook. Eh?

It just did not strike me, that the problem at hand was the same problem back in my observation notebook. This is the greatest shortcoming of my formal education. I just did not pay attention to the one thing that will be of help to me. I did not pay attention to mathematics.

Lest, I give the reader a very wrong idea, given a problem from the mathematics text book, I knew how to arrive at the solution by applying a bunch of formulas. My entire attention was on the procedure to arrive at a solution. It made the most sense to me because, 1) this was what the teacher focused on and 2) the procedure and the solutions were the one that was going to fetch me marks. But procedure and solution are of very little use in real world when you are trying to solve a problem, just because of the fact that, you do not know the procedure.

What I failed to notice was the order and method through which the procedure was created. It is all to easy to remember the derivation of E=mc^2. But this does not make anyone Einstein. There is analysis that goes into coming up with an algorithm. No one can sit and think about how to solve a problem and solve it. One must analyse the input, figure out its nature, its properties, its relation to other known concepts, its relation to the output. Only then, It is my belief, that one can see the way.

But this is what a mathematics text book always specifies. They mention the input, its relation etc, and you just apply the formulas. But in real world, no one is going to write down, the properties of the input. No one is going to specify the fact that the input is a fibonocci sequence. No one is going to write down the input as a nice and clean linear equation. No one is going to give the input in a nice and neat linked list and ask me to find the middle element. I have to figure that out for myself. That is where analysis comes in, and there should be order and method when I analyse a problem.

Time and again, I have caught myself jumping to the next step in the solution without taking time to analyze what I have in hand. It is just the way I have trained myself to look at problems, and It is my first goal to unlearn this and start analyzing the variables at hand. Towards this end, I have started watching the mit open courseware on algorithms, this time around to pay attention to the techniques that the professor uses to analyse the problem, instead of the end solution. Formal education is not a waste. I  just have to pay attention to the more worthwhile subjects.

Quote for the day,

“Projects don’t succeed by jeemboomba magic” – Dr.Nadarajan