In the early days of the PC, there was little to no source code to purchase. There were the major applications like Wordperfect and Lotus123, but no source code that you could purchase. In those days, you did it yourself. You built everything from scratch so that you knew it worked, how it worked and that you could troubleshoot it if something went wrong. It was cowboy application development. Software guys (they were always guys) were the loners in the basement building applications all by their lonesome.
Now, of course, everything has changed. Applications are big and complicated. Too big for a single developer. There are software teams instead of lone software guys. There are even females doing software – not many, but more than there were twenty years ago. These teams are under pressure to get these large applications done fast and done right. Their employers can’t afford the luxury of reinventing the wheel and building everything from scratch.
That’s part of the movement to open source and the success of companies like ours that license source code. You can get a product out the door faster with less effort by using software already developed and tested by someone else. Now I’ve argued previously in these blogs that licensed software is worth buying over using open source, and that this is especially true in Industrial Automation, but I won’t repeat those arguments here.
Instead, I’d like to talk about THE one key criterion for selecting a licensed software product like OPC UA Source code, EtherNet/IP Source code, or ProfiNet IO Source code. That key criterion is the API – the Application Programming Interface. There are several key features of a good API:
1) Simplicity – You test this by calling the company and speaking to the people that support the product (can’t do this with open source). If they can tell you quickly and simply how the API works, then you have winner. If not, you may be in for a long development.
2) Scalability – does it work well for the single user/application/device case as well as for the application deployed at scale?
3) Documentation – Is the documentation readable. Better yet, does the SDK (Software Development Kit) include sample source you can use to implement the licensed software. If there is a well-documented file showing how to use the API that you can steal and deploy, you won’t even need the documentation.
4) Completeness – This is, of course, the enemy of simplicity. The API should provide enough to get the job done without providing the five thousand other bells and whistles which satisfy edge cases at the price of added complexity.
Documentation is always difficult. It’s the last thing to get done and is generally thrown together at the last minute. But it can be really important. I thought that Phillip Lhoste on Quora gave a great explanation of what’s needed in API documentation. He said “…doc should be complete: it should not leave some functions or parameters undocumented. It should be consistent: a reference should not hesitate to repeat information, either directly or by making a reference to a section common to several parts. Users rarely read a reference from top to bottom, but often jump directly on the section they need help for. So doing implicit references to previously given information is a bad idea.”
A customer gave RTA a great comment the other day. He said that he was spoiled by the APIs we’ve built for EtherNet/IP, ProfiNet IO, and Modbus TCP. He had to use another vendor’s product on a project and was overwhelmed with complexity.
But that’s what we do here at RTA – we provide simplicity so that you can get the job done faster and more efficiently. Try us – our inside technical sales team is waiting to hear from you. Email email@example.com or call 262-436-9299 for more information.