Did you take the “Pacemaker Test” before shipping your code ?
As a developer, the onus of delivering a functional, working code is always there on you. Whether you were there in the sprint planning meeting or you got the requirement specs over email in 2 sentences (“I need the login to support social auth. Should support ActiveDirectory too”), the moment you commit your code and say “Done”, do you realize there is lot more to it ?
There is a large population of developers who deliver the requested functionality as-is to the Reviewers(Reviewers may include peer-review, Manager or the QA team), and leave the tough job of thrashing the finer points to Reviewer and point out gaps in the code.
For all such developers, they should take the “Pacemaker test”.
Pacemaker: A system that sends electrical impulses to the heart in order to set the heart rhythm. The pacemaker can be the normal “natural” pacemaker of the heart or it can be an electronic device.
Just suppose you are in the team that is writing software for implementing the pacemaker algorithm, i.e to monitor heart activity like irregular and slow heartbeats and in response to these events, send out electrical impulses to the correct region of the heart to enable contraction.
So, just suppose you know that as all Software teams have, you also have a QA team which will test your code endlessly to make sure your code works flawlessly. Now you have two options:
- Apply your programming knowledge and algorithmic implementation to generate the code, while covering all possible scenarios like gaps in signals, missing signals, invalid signals etc., and make sure you have, as a developer, tested your code thoroughly for all conditions/exceptions etc. before shipping to QA (or reviewers) and you know in your heart that your code doesn’t contain any issues that would be uncovered by the QA.
- Apply your programming knowledge and algorithmic implementation to generate the code as per the specs given to you and handover the code to QA. You know that the QA team (or reviewers) will always catch any bugs before your code ships to production and to pacemaker devices to be used across the world.
Before choosing any option, realize the following 2 truths of the world:
A. QA (or reviewers)Teams are also human-beings and it is possible that they miss any corner-case or an unhandled/un-imagined scenario and any QA-verified product may be released to production with a bug lurking somewhere.
B. Since you don’t know which countries and which patients will be using the produced pacemaker device, it may also be used by one of your near-and-your-dear ones (god forbid!)
Will the above realizations (A,B) impact your choice (1,2) ?
- Most through/diligent developers will choose Option 1 by default.
- Developers who choose Option 2 will most likely change it to Option 1, after going through realizations A & B.
- Developers who stick with Option 2 even after realizations need to learn more about ownership and empathy. Having empathy makes you realize the impact (good) your piece of code is expected to have, and will have on your end-users and the consequences Incidentally, even the managers of such developers also need to introspect whether they have been able to show the greater impact of the work the developer will produce and how much motivated the developer feels ?
So, while developing any piece of software (even if it is a hello-world or an ERP or any code), just apply the above principles to ensure quality — imagine that your code means life and death for someone.
Avionics
If the concept of pacemaker sounds too grimy for you to consider as an example, you can consider the software to govern Avionics in a fighter-jet which your best-friend might be flying (Yes, he got into Air-force, while you chose engineering). Imagine your friend depends on your software to guide his actions at a height of 50,000 feet in air, and a slight oversight on your part while producing the code will cause chaos to his Jet, and maybe to his life. How much quality would you ensure while coding that piece ? I am sure you would run your code through endless permutations and scenarios before giving it to QA.
You can consider yourself a great programmer when you start applying the same diligence to all your pieces of code — it maybe the next one project is a cutting-edge high-frequency algorithmic-trading engine or a mundane user-login system.
Instead of thinking in terms of value of your work, think in terms of Perceived Value of your work. You may be creating the code for a note-taking application, but it may mean a collection of notes, recipes, to-dos and an efficiently organized life for someone.
Show-Me-How
How do you ensure water-tight coverage and ensure highest quality of code ? Many developers rely upon the product managers to work out a story and the devs themselves are a passive stakeholder. Nevertheless, the devs can ask themselves if they have the following answers before putting down pen on paper :
- Do I Know who the user is, why he/she will use software ?
- Do I Know how the user will use my software ?
- Do I Know what will happen to the user’s intentions if the user doesn’t use my software ?
- Are there better options to him to get his task done ? Why are they better ?
- Do I Know how dependent the user will be on my software to get a particular task done ?
- Do I know the unexpected ways in the user may use my software (eg: Entering IP address in place of a FQDN).
- Does my software handle the three states — Regular, Blank, Error ?
- Are your messages user-friendly or jargon-filled ? (eg: “ERROR-2018. The record could not be deleted successfully.” vs “The song from your playlist could not be deleted. If reporting to our support, kindly mention ‘ERROR-2018’ ”)
- Does your Software “Talk” to the user ? (eg: Showing “Seems you have a new playlist. Let’s help you with finding songs of your choice <Button -Explore Genres>.” is better than “No records found” when user creates a new playlist.)
- Is my software easy and intuitive enough to get the user going without the help of any manual or assistance ?(Eg: Gmail, Netflix)
- Is it possible that the environment in which my software is running or deployed may change ? (eg: The user may be using my device from an Emulated OS or running on a 2G network.)
- Is my code handling those changes or communicating to the user about those changes and its impact on his/her experience ?(Eg: Adpating to lower bitrate or showing “Seems you are on a slow network”)
- And lastly, did you think about converting your code from a “Software” to a “Product”. The moment you realize the difference, you are ready to make a mark!
Creating any work is easy, but creating a great work is boring, tiring, demanding, and you are often alone in creating it, and what keeps you going is that it will impact someone’s life somewhere immensely. You gotta do what you gotta do, no shortcuts!
What’s your thought on personal qualities a good developer should have ? Do let me know in comments!
