Why programmers hesitate to work on Robotics Process Automation Products/Tools

Programmer might be hesitating by thinking its non-intrusive job without API / Web-Service and Coding. I would like to stress, industry in matured now and we can’t keep coding the system. It’s time to use the AS-IS system. More importantly there are many legacy applications / systems / platforms in the industry which has limitation to code further, so best options left is non-intrusive development.

Last but not least, an adviser can use the robotics tools/products but it’s only a programmer who can build the intelligent soft bot using these tools. Also please don’t forget next era of industry is machine-learning.

Sorry but I really don’t have answer why programmer hesitate to work on robotics process automation tools. Instead I can share lot to motivate programmers to work on these tools:

1. Do not think you are using these tools; you need to think you are building soft bots for the business. You are a step ahead of programmer
2. I bet a non-programming guy can’t built a soft bot just by so called drag-drop commands of the tools
3. Soft bot is not just a drag-drop but it’s a development of algorithm and instructions with all best practice of software engineering to perform the task
4. As per computer dictionaries a software program is “a sequence of instructions that a computer can interpret and execute”. Similarly a soft bot also is a software algorithm that are designed to perform repetitive rule based tasks and operation that are currently performed by humans.
5. More important what about the scenarios when build-in commands of any robotics tools can’t full-fill the business need. It’s only a programmer who can quickly build its only software component and consume it.
6. Best practice: A programmer can build a soft bot by religiously following best practice of software engineering:

• Keep control structures simple– Limit your branching, don’t have long nested if, case, and loop statements, no recursive magic.
• Endless loops– Do not use boundless loops unless you really want to be stuck there forever (such as the main loop). Everything else must have an upper/lower bound for exiting the loop. Think more about for loops than while
• No dynamic memory– Forget that malloc It can cause programs to act differently at each run time, also can add memory leaks which can be hard to detect.
• Asserts– asserts are good since you can enforce that the proper thing is helping in each function. I generally do not like the default assert functions that just cause an exit; sometimes that is appropriate but in many cases you should try recovering from the error instead of just exiting. You need to evaluate which is the safer approach in your application.
• Exception Handling – A programmer code should never break.
• Fail-over mechanism: What if desired and happy path algorithms fails.
• Keep scope– Try to assign and initialize variables, structures, etc.. in as small of a scope as possible. Included in this is limiting your usage of global variables.
• Check return value from all (non void) functions– If a function can (and should be able to) return an error value make sure to catch it and act on it. It can also be good to check the bounds of a value returned instead of blindly trusting it.
• Turn on all compiler warnings– So you catch things early. This can especially be true when formatting text, working with memory, and when bit banging.
• Use formatter to control order of operations– I have seen many people assume or forget about the proper order of operations. Using formatting can clarify and enforce the desired result.
• Hard coded number– Please use variables for any value that might need to be changed by a programmer. If you have an even slightly non obvious number, give a comment about the source of that number and how to derive it.
• Standards– Keep your code consistent. This includes naming, white space, and where your curly braces go. This makes it easier to follow the code. If you are editing existing code use the format of the existing code.
• Sleep with noop’sor empty for loops – These should be avoided since they will run differently on different systems. This is primarily for embedded systems.
• Document your code– Do I need to say more…
• Re-usability: Build a bot by re-usable components. Build a bot so as other can re-use your bot components.

 References:

https://robotsforroboticists.com/software-engineering-principles/
https://www.thefreedictionary.com/software+program
https://www.ald.softbankrobotics.com/en/cool-robots/cool-tools
https://www.blueprism.com/
www.uipath.com/automate/robotic-process-automation
https://www.automationanywhere.com/products/automation-software
https://www.openspan.com/products/robotic-automation/