0Let me tell you about pencil programming and user centric approach.
But before that a story and a bit of background.
It was a normal morning when he was just out of the meeting, requiring him to start working on a given task of invoice generation, at earliest. The customer was expecting this functionality to be available as usual yesterday.
Fortunately for him, the requirement was very clear. He received UI from a designer in a couple of moments. Sleeves up, he came to his desk and opened his favorite IDE. Opened the project and included UI for given task. Finished this part quickly and ran the project to see how UI looks. It was acceptable. He then started writing necessary code.
By evening, he was done with the coding too. He ran the project again for unit testing. Boom! There was an exception thrown. He struggled with it for some time, debugged by putting breakpoints in several places, identified the error and resolved. He ran it again to see the error gone.
He went further into his unit testing and started creating one invoice. He realized that totaling of invoice items was wrong. He debugged the option by putting breakpoints wherever he thought useful, identified what was wrong and corrected it.
Once more he tested the option. Again, he found that tax was wrongly calculated. Even though he selected correct applicable tax code from the lookup, the calculation was incorrectly stored in the invoice table. He again looked at the code and found that the lookup was incorrectly set due to which, always first tax code from tax table was taken up for calculating the tax.
Cursing himself, he corrected the mistake and tested option again. This time it was up to his satisfaction. Test Engineer was waiting for him to complete development so that she can test and pass it from QA perspective. He gave the new build to her for testing.
She started with her test cases, one after the other, mostly marking those negative test cases as “Failed”. For example, invoice generation option allowed selecting a customer from drop down list. However, it also allowed her to type in any name she wished, resulting in exception while saving. Same for tax code selection. Moreover, she could enter invoice date, as old as 21-Oct-1916. Due date was then calculated wrongly because of wrong invoice date. The receivable report was showing this newly added invoice as absurdly overdue.
Apart from these, there were a couple of low priority, but important, cases from a usability perspective. For example, tab order of input wasn’t in proper sequence or when clicked for new invoice generation, the option did not focus on customer drop down list which was supposed to be the first input, or calendar control to pick up a date for date inputs wasn’t set to current date etc.
After giving him the list of issues, she went home and was be in the office tomorrow early morning to test the option again.
He had to sit down correcting those issues, maybe a late night or even overnight, and yet should be available to look for any other issues she raises next day. That built pressure on him. He was required to clear a couple of cases before the sun rises next day.
Think of yourself in his situation and think of what could be avoided in such situation, in the first place. Here are some bits for you:
In ancient times of the 80s (not really ancient but technology is developing at such a pace that you become dinosaurs quickly), I used to work on a PC. Do you know what that meant? A CPU, a black or green monitor, a keyboard and a 5-and-a-half inch floppy drive.
Did you ask about hard disk? What’s that? Oh, you mean those bulky storage devices with weights more than every other component combined? No, such PCs were given only to the super heroes then. I wasn’t.
So, I used to write a program in BASIC using the most clumsy text editor of time. You would design even UI by hand, writing code to draw horizontal and vertical lines just to form a border for the screen. Using operations as simple as copy/paste was a task then. Those programs I used to save on floppy disks and then used to give it to super heroes for incorporating in a directory of DOS based system (let me call that as a project) and checking (I don’t remember if “testing” was the term used at that time).
Super heroes would check and come back to me if they have any issues/errors with the code. During the initial stages, I was bombarded with issues in my code and I was embarrassed like anything because every other programmer will look at me as if I have committed some crime. And mind it, it was. It was criminal wastage of time because the same PC was shared between 2 or more programmers. PCs were just too costly you see!? More costly than us probably.
Okay, enough of my story and background. The point is; the criminal wastage of time taught me something which no school teaches you. It is called pencil programming.
Simply put, I started writing down the objective of the task I am programming for. Wrote down every minute detail, scribble and see how UI should look like, got it approved by super heroes, wrote down what each code fragment will do in bullet points or pseudo code. Once completed, I would go through the paper(s) once again. Thought about it once again and ensured that what I was doing was fool proof. Once I was sure, I would ask for a time slot on PC and then work on it.
With this, my performance was drastically improved. My code was not only bug-free but if anyone pointed out any mistake, I was either quick to justify my point or I was quick to correct the mistake, because I had thought about it, well.
Pencil programming was very beneficial then and today I find it far more important and necessary tool for every software engineer.
In the fictitious story above, he could have spent maybe 1 hour more in programming the task using pencil first, to avoid late night or overnight working and making his own life more stressful.
Think of it and justify it yourself in your own work. I am sure this small step before putting hands on codes will prove beneficial to you. Because that makes you think over the task first. And when you actually write code, you know exactly what you are doing and hence you know exactly where to look for when error or exception occurs. You do not panic and do not wander pointlessly through the code. A big plus.
Second very important point is to have user-centric-approach. The user of your application has to use whatever you give him or her. If she/he is happy using it, Kudos! You made it. But if she/he is unhappy, s/he can ruin all your sincere efforts. Mind this well, we exist because there is user.
Apart from basic expectation of functionally working form, it also helps if user can use it with minimum efforts. I have seen how end-users struggle with mouse, while with keyboard they are quick. If tab order is not in correct sequence on the form you designed, they will need to use mouse to point and click on next input. Waste of their time. Similarly, if you don’t focus the first expected input automatically on a given form, again user needs to use mouse to point and click on it. Waste of time again, for user.
Think of yourself as a user of the form you designed. Are you satisfied? Can you use this option daily? Is it helping you in quickly finishing data entry?
Think of user, because for you, you are going to work on this form only once, but user is required to use it daily for many number of times. Little extra efforts from your side will make his or her life lot easier, daily.
Please remember these two key points about pencil programming and user-centric-approach. You may mistake it as an additional work requiring you to put in extra time. But try out. It will reduce a lot of reworking at the later stages.
Try out and experience the joy of programming.
