Robotic Development Center


No one likes documenting, especially developers don’t. Though planning an automation can be useful, it may give you insights on reusable components, as well as hidden complexities discovered early instead of when you are well on your way with development. But over documenting can also unnecessarily lead to loss of ROI, on a poorly chosen process with already low ROI, this can be the difference between saving money or wasting money.
So should we not document at all? Of course not, in the long run its important to document key knowledge, people leave, vendors change and knowledge fades.


As all vendors have shown on conferences pre-covid, you can build a bot in minutes, its easy and everyone can do it. Although.. If it would be so easy, why didn’t your own IT departments already fix it with traditional development? Corporate landscapes can be very complex and have landmines all over the place, stepping into someone else their territory may turn friends into enemies. Without the proper perspective a ‘screen scraping’ solution, using mouse coordinates and keyboard entry ‘tab tab tab, enter something, tab tab tab’ may seem tempting. It’s exactly copying what the employee would do, so it must work. But the toolbox called automation has so many more tools in it, partnering with IT may suddenly open up API’s, databases. Giving more reliable and sustainable ways of development, preventing down time and high maintenance cost.


Testing perhaps is the most underestimated of all phases, perhaps sounding easy, but to test in a structured way, debugging issues and resolving as we go, takes experience. The easiest way is to simply run a automation, no test cases, and see where it gets stuck, try to fix it, run again, and repeat this cycle time and time again until the automation seemingly succeeds. This way of working adds unneeded test cycles and potentially makes you fix issues that only occur once a month in thousands of runs, delaying deployment of the automation for a 0.01% increase in success rate. On the other side of the spectrum, bugs might be missed which actually will significantly impact the success.