It’s wonderful how fast technology and computer science have progressed. The automation and ability to hit a big green button, instead of spending hours analysing and testing your written coding is amazing right?
Yes, it is, but…
The problem with this automation is that it can cause more errors than humans do. Human error has been trumped by the computer errors. Hey guess what humans, you’re for once better than machines… knew we’d get back on top one day…
The reason for this is caused through lazy programming. We are getting less and less people with the skills necessary to understand the background work of that lovely green button. Every piece of the process involved with how that button functions needs to be understood. Computer systems will change and react to users needs, based on requirements for software advancement, but need to be tested and understood before being used.
Programmers have become lazy, actually the management has become lazy. The project goal from all sides;
1. Management – Build a box with three windows and a door.
2. Project Team – The wood needs to be weather resistant and have guttering to deter water damage.
3. Programmer – I will place the windows on the ceiling, as they provide the only weather resistant addition then add the door to the non entry side due to security concerns.
4. User – How the fuck am I meant to get in this thing?
Delightful little view point…
The system isn’t this dumb, but it shows how ignorance of all parties can contribute to failure. Which unfortunately, most system developments follow.
I work backwards from the goal. Don’t listen to Management. Get the User input, they are the ones who matter. What do they want? Then we program their needs into the development, then move to the project team to test and make additions to their needs. Only then do we need it to be tested and displayed to Management for final approval. This will change the format of the steps to be;
1. User – I want to be able to go through a door and look out windows on each side to see the view.
2. Programmer – I have placed a door that the User can access and have given them the ability to see through the windows on each side.
3. Project Team – Can we please weather proof the current structure, so it will be alright in rain?
4. Programmer – I have added the weather proofing.
5. Management – This is just what we needed. Thank you.
Much better, and more effective right? Sometimes flipping something the other way around makes the project or the effective measures more manageable. So, instead of starting a project on a simplistic scope, we instead go to the needs/wants of the big picture. I am not saying every need will be achieved or implemented, but that is our start. Next we ask the Programmer, who has different parameters on their abilities or the software design. Then we go to the project team who control the software and their knowledge/abilities of what the system can do. Once all developments are functioning, you can present to Management for final approval.
Stop there. Now comes the hard part…
TEST THE SYSTEM!
Do not just test it once. Do not just test it based on your knowledge. Do not assume it will work with every try. Do not assume a line of code will not be corrupted by an update to any system involved. Do not think this process will not fail. Everything breaks…
“Everything breaks, the only things that last are things you are willing to fix.” – Bradford Winters
Know how to fix the program, understand the code, understand what the process is. Have the knowledge to fix it. Don’t be ignorant, don’t expect someone else to fix it. Learn, understand and teach.
Now forgive me sounding like a grandmother, but when I began coding, it was an art form. We did not let a lazy person press a button to take credit for our artwork. Now, we sell our buttons to allow idiots to use our precious work and get paid poorly for our high efforts. See all those lovely buttons in your applications, software and programs? They have all been made by an underpaid programmers blood, sweat and so, so, so many tears. You see a quick button where I can see the syntax errors, the version/update errors, the software comparability errors etc. Etc. Etc.
It drives a person insane. So before requesting new improvements, before complaining, before criticizing something you can’t understand… stop yourself. Unless you are willing to spend the hours learning how you can initiate change, don’t expect a programmer to fix your needs. They developed your system, now you are responsible. They built your house, now you maintain it.
Basically, Go Fuck Yourself…
Maxine the Magnificent 