My mother's threshold for discomfort is very low. She often comes to me complaining how I can wear so much clothing in such hot weather, or demand I put on the layers to withstand the cold. Once in awhile I remind her, "If
you feel so hot,
you can take off your clothing."
This is really not a case of parental complaint. The point I wish to highlight is: people are by large insensitive to the feelings of others (My mother's core problem is she thinks everybody in the world feels the environment/climate in the exact same way as herself). And this is perhaps most evident in technically inclined individuals possessing knowledge and skills a gap above laymen, especially with software programmers and developers for the interest of this post. And I can say this because I am like so.
Developers have a special power to mold
thought into a manifestation that can enhance the lives of others. But how
too often is it that we completely forget the software we design and write are ultimately to help the users, and wander with our own visions of what is useful, easy, accessible, and usable. The result of a highly complicated system nobody likes to use, or even get frustrated and angry at, is just way too familiar. Building software without considering what users think is like constructing a ship with no doors to the bridge.
And before I "mislead" you further, I request reading the subject title once again. The notion I wish to push here is that software in reality has two forms and two sets of users:
1. those simply take the package and execute the provided functions to accomplish certain objectives in their lives. The end-users.
2. those who prepare as well as inherit the technical "blueprints" of the software, and to manipulate in order to produce the package. The developers.
In a conversation with colleagues, it was mentioned no matter how well archictected, designed, and engineered the technical solution and code are, end-users are not going to see a single bit (can be taken literally or not) of it and likely don't give a damn either; all they want is the software to work effectively, efficiently, reliably, safely, beautifully, wonderfully. And true enough, in the race to meet customer/user demands (which by nature are infinitely insatiable, thus the existence and enforcement of legally-binding requirements and specifications documents) developers rush to write code with the pure intent of accomplishing, item by item or task by task, the required functionality without being over-schedule and over-budget. Given the grossly immature mindsets and underestimation to the complexities of delivering software that actually works properly, it is near impossible to find a software project that involves money to be stress-less for the development team. We are building the digital Great Walls of China and Pharoahic Pyramids. Make no mistake about it - we may not be losing our lives but we are losing our lives.
Refer back to my colleague's statement. Nothing new there; a sentiment communicated over and over between developers since the dawn of computing (I believe.... I wasn't born that long ago). It almost seems like it's a actually mistake to spend time planning a proper architecture, sensible object design, and high quality code. In our haste to cater only to end-users, we give those issues the finger and plunge into abysmal engineering standards. However, my response to that statement was, and still is, "Absolutely. Architecture and Design were never meant for users. They are for
developers to consume, and
use."
(Regarding that, administrators who are essentially users definitely do require more of such knowledge, but never as much as the application designers and developers.)
Software rarely stays in v1.0.0000. And for software that ages with versions, it is rare for the exact same team of developers to stick together till death do us part. Like baton-relay races, software development changes hands. Regularly. And being the insensitive programmers we are, we issue out code that makes sense to us, and to our own selves only, _for that moment_, and move on to another item once the functionality is somewhat completed. The result for another person looking at the work?
Conclusive evidence why most of us cannot write documentation and books, according to Martin Fowler.
Once one starts writing code only for the computer to read, any sense of security of driving cost down is plain falsehood. Insensitivity to how others would interpret one's code (thus "use" it) will simply drive the cost of software development up as the 70/30 rule continuously gets enforced, by unconscious habit. Since people gone by obviously aren't
securing their job position in the same project, it becomes clear their thoughts contain no concern of how future developers can easily consume their blueprint for modification and enhancement. Time is money. Everybody is taught that at an early age. It should be simple logic then, to see that 70% of developers' time spent figuring out what's exactly happening in code is
wasted money. Certainly, we cannot eliminate that to 0%, and to completely fault it on developers will be a blind eye on the fact that the performance matrices passed down by management usually fail to capture this. As with so many other unfortunate strategies by management - penny wise, pound foolish. Taking this into account and seriously engineering some good intuitive design and
self-documenting code will go a long way.
Do you have the practice of typing down your name into comments in code and design documents? Has it ever crossed your mind how people will react as they inherit your works in the future? Will they sing praises and psalms in your name? Or will they angrily curse your name in hatred and deep anguish?
How about we start learning to treat our fellow developers as users of our design and code? And write software firmly designed for developers.