Module complexity - what to include, what to leave out?
The LEAP thread, and others of the years brings up an important and timely conversation. When writing a driver, what do you include and when does it become "bloated?"
ITG = the Integrated Technologies Group -- aka the team who make developer resources like AMX created device drivers. In general, we have two rules when creating device drivers:
1) Code for full functionality of the device protocol because every integration project is different and programmers always surprise us in the features they want to use.
2) If it is a configuration item, likely one-time use during commissioning, we generally do not include it.
If ITG is lucky enough to receive hardware to test against, we generally only have access to it one time and need to test all of the functionality while in possession of the actual device. ITG is a relatively small team and it is difficult to revisit a module for feature enhancements that come in after a module is released because there are other requests in the dev que, and the hardware may have been shipped back.
In your own module writing efforts, where is your line in terms of features to include? Do you have a defined list of "must-have" commands by device type? Is your rule to code to the job requirements and nothing more?
Our goal is to deliver device drivers that meet your needs, and easy to use and implement, and ultimately solve a problem for you. We understand that there will always be a gap between what is found in InConcert and the devices you are encountering in your projects. In some cases, you will need to write your own driver or block of code to interface with a new device. When that happens, what are you including? Many variables go into this decision, and I would like to hear from the community on the topic. Most projects do not take into account any time needed for driver creation, let alone a fully developed driver that encompasses all of the capabilities of a device. The risk to the business (independent or company) is a reality that we may never encounter this one-off type device again and any time spent beyond the project requirements is lost revenue.
What are you including in drivers you create?
What would you change in terms of what AMX includes in drivers they release?