So, is it Simply or Only?
As a software developer there are two words I really hate – SIMPLY & ONLY.
How many times, while trying to explain the way something needs to work or having what you think is a meaningful discussion about a problem, does the person interject with “but it’s SIMPLY a matter of …” or with an equal level of constructive input “you ONLY need to …”. These two words can end up costing you many hours or in fact weeks of your valuable time.
“But it’s ONLY an App with a couple of SIMPLE buttons on the screen. What do you mean there is a server back-end?”
It’s not ONLY an App. There are; the styles, colours, user-interface (UI), user-experience (UX), fixed IPs, SSL, firewalls, access credentials, even NSA requirements. Again, you get interrupted.
“You always make things more complicated than they need to be.” ... Apparently!
The truth is nothing we do in this world is SIMPLY or ONLY anything. We might be thankful for Object-Orientated-Programming, Inheritance and Libraries, but the fact is like all magic “it comes with a price”. Protocols, Interfaces and Standards are a curse. As a programmer, you now need to understand and trap the 1000 other things supported by these frameworks even though you really don’t want to know about them. You wonder why you chose that Object, Class or Library after coding around the impact that it has on what you are trying to do here and now.
The job of the software programmer is to create a good App/Program that is SIMPLE for the main-stream user. This means that the user ONLY needs an extremely shallow understanding, usually limited to the App/Programs primary objectives, of how anything actually works. The difference between a good and great App/Program is the level the programmer goes too in order to satisfy every possible relationship/framework/networking/timing consideration and then predict the many potential conflicts (bugs) that could otherwise occur. Oh wait. No!
In this new world it’s all about the “User-Experience”. That’s what really matters! Yeah?
An App/Program must be intuitive and draw on the user’s prior App/Program operational and interactive knowledge of data entry and presentation techniques. The user likes to be able to do things “the same way as other apps”, even if it’s not necessarily suitable for the new task.
Although most users will voice an objection to their identity information being stored or held online by a company (like Apple, Google or Facebook), they are the first ones to complain when a new App/Program asks them to set-up a new account with another User-ID and Password, instead of referencing, say the Facebook one they already have.
No-one likes to remember passwords!
Most users consider themselves “Time Poor” giving them a plausible excuse. In fact I think it’s that shallow level of understanding that makes them reluctant to learn a new way of doing something. They don’t want to feel stupid, or ask for help, so it’s the App that’s not doing it right! If you want your App/program to become popular then you don’t want to put your market offside before you even start.
Then there’s the problem of getting paid for your valuable time. Those two words SIMPLY and ONLY really get in the way when justifying your actual research, planning, coding and testing time. Why does a plumber get to charge you for reading the manual on installing your new water heater, or for re-doing that leaky pipe joint he only just installed, poorly, because it failed a pressure test? Maybe I should have been a plumber – they certainly get paid much better.
I remember being asked once, to debug a program running on a dedicated Linux based controller board. It was written by someone else, who was no longer around, and although it had been in service for several years, the controller board had a minor bug. After two days of getting into it, I made the one line code change. The bug was now gone. The customer, now happy that it was fixed, refused to pay for the two days of my time as it was SIMPLY a minor bug and ONLY one line of code that had to be changed. Probably my fault for disclosing the actual work performed. My honesty does get in the way!
So, is it the customer’s inability to value your expertise in understanding the process necessary to read, learn and make changes to someone else’s code in an unfamiliar and dedicated environment , or is it SIMPLY that they can hide behind their implied ignorance to justify ONLY paying what they think that the job is worth.
You know, maybe ignorance is Bliss!
“If ONLY it was SIMPLY a matter of …”