Software professionals need to care about the implications of their creations and the different ways it could be put to use by the end user. Let’s take a look at an example of how the software you develop can have unforeseen consequences.
The business need: “I want to access our students' basic info and mail it to companies in their majoring fields in order to help them get a job as soon as they graduate.”
The entire development team starts to work on it: sketching, asking for examples, writing tests and then coding, carving details and testing some more. The feature is finished and the product is shipped.
Now to the end user...
A career counselor at a university has the new app and is ready to help his students out. He chooses the background, font, recipients and publishing date for the email, and also the name for the campaign and the majoring careers to be included.
As he finishes his task the snacks trolley happens to pass by, and he chooses a cake over an apple. Is it our fault that our creation drained his cognitive resources which happen to rest in the same pool as willpower? Yep, by providing the user with too many (maybe useless) choices our application could be what is making him break his diet.
Now to the real issue and end user...
On the other side of wire, emails start reaching candidate inboxes and new opportunities start blooming. Those with A grades receive great offers, B students get OK offers and C students none at all.
Basic info includes a global grade obtained by the student during several years in college. But wasn’t it supposed to be only basic information? Nobody questioned at the time of the build if this field in the database was a good idea to include. The result, employers are seeing a skewed representation and making a decision that isn’t based on real potential and students will suffer.
All because of the software you helped to develop.
So now our creation has had an unforeseen consequence, because, as explained by Professor María Belen Albornoz, technology is not neutral. And for software, this means code has some implications we may or may not be aware of.
These two agents into coding, unknown to me just a few days ago, poses a question we should ask before start coding: what is this software really for? Because you might be writing a tool which enforces/encourages a principle you don’t share. Sometimes this question may be answered simply by asking who asked for it. Sometimes you will need to reach for someone with better knowledge. Either way, let’s be more mindful as programmers.
And also, this got me thinking about something we should ask while typing every code expression: is this the best way to do it? Because if it is not I might harm the function and I might harm the structure(1). And even more importantly, the unintended consequences may end up hurting individuals.
All said, purposeful coding should be included into our everyday work of creation. A code where we denote our intention (to do good, hopefully) in every line. A code which cares about its user and knows the place it will have within the big picture.
(1) The Clean Coder: A Code of Conduct for Professional Programmers, Robert C. Martin, 2011, Kindle Location 516 of 3791