Machine-dependent vs machine-independent device software

 

Definitions

 

Machine-dependent software is software that addresses specific hardware features and works with only one type of peripheral device. Device-dependent software refers to programs that can run only on a certain type of hardware (i.e., their ability to function depends on the devices on which they run). Device-dependent software cannot easily be ported from one type of device to another, and usually requires large-scale modifications or rewriting of the original program. Device dependent components work properly only with a particular model of the device.

 

Machine-independent software works with a variety of peripheral devices. Device-independent components work right no matter what model of device you use them with. For example, a given program doesn't have to worry about how to work with every mouse, keyboard, printer, screen, or scanner on the market. Instead, as long as the environment has a software control module (or driver) for the devices in your system, every program will automatically produce the expected results. Alterations to the software are usually not needed, and are minor when they are. Such software, however, has to contain within itself a considerable amount of information on the characteristics and capabilities of the devices it will work with.

 

Advantages and disadvantages

Keep in mind, my opinion is subjective and I may be wrong, but it’s still seventeen years’ worth of experience.

 

Evaluation of operation speed and time needed for manufacturing 

• Machine-dependent programs take far less time to develop, reason being device-dependent programs are actually a package consisting of several layers, only one if which is machine-dependent. Even if there are no gaps in the technology and experience, their manufacture is more complicated from a purely technical point of view;
• Generally, machine-dependent software operates faster with a given device, as there are no intermediate units where translation of the machine-independent logic of the program to the specific device and the device’s reply (if any) is required;

 

Maintenance

• The maintenance of a program created specifically for one kind of device is normally easier than maintaining one designed for tens of devices. However, should it later become apparent that this particular program will have to support more than one model, its maintenance sets upon the path of failure and the speed at which it will be reached depends on the number of new devices and how different they are from one another. When given such a task, do ask plenty of questions. That will save you a lot of stress and effort later on. If you’re developing your own solution, then feel free to develop from the very start with the idea that you’ll be maintaining more than one device. The world is such that if your project is viable, it will undergo changes even if you think the hardware you’ve created is perfect;
• If a machine-program is developed according to a given standard, its long-term maintenance becomes much easier. As we will see later on, the presence of a standard which describes and requires information on a certain set of characteristics and capabilities on part of the drivers of different models leads to a significant mitigation of the needed effort while implementing and maintaining new devices;

 

Approaches to developing device-independent software

I love the following sentence for the pointlessness and obviousness of the information it carries. The development of device-independent can be approached in different ways. The truth is the majority of people love hearing obvious sentences and if you don’t talk in obvious sentences because they are in fact obvious, they take you for a freak, curmudgeon or a smart alec and the conversation is off to a bad start. Over the years I’ve realised that if someone asks you a question about something obvious, it’s actually better to waste your time and reply without emphasizing how obvious the answer is. It’s simply good for business and besides, not everyone may know things which seem obvious to you, just as I am certain that in ninety-nine percent of cases, readers of this article don’t know most obvious things related to growing broccoli.

Still, let me get back to approaches to cross-platform software development. 

• Your software is going to be the result of the intersection of all the available characteristics and capabilities of the devices. If it’s a SDK, it’s possible that the list of features, capabilities and methods to be much shorter than such a list for any of the devices. If it’s a fiscal device, the intersection (or minimum) is sometimes determined indirectly by the laws of the specific country, which require every fiscal device to implement them. Strange as it may sound, such minimisation is possible and is often enough for business needs;
• The software is a product of standardisation related to the needs of businesses in a given area. As a whole, every type of standardisation leads to lists of properties and capabilities, which some of the intermediate layers pass on to the layer which communicates with the user application; 
• Depending on the end business goals, software can be:
  • Single-layer - everything that is needed is located on the same computer to which the relevant device is connected;
  • Multi-layer - some of the necessary device management software is on the computer, while other part/s of it are housed in a remote server;
  • Cloud-based - part of the device management software is located as a service in a given cloud (private or public), while the device itself is designed to communicate directly with that service. In some cases, if the device doesn’t possess such capabilities, another intermediate layer is developed;

Personal preferences

Over the years I’ve learned the following:

• The more remote a programmer is from working with end users and software maintenance, the more likely they are to try to convince you there isn’t a need to develop machine-independent software. In some specific cases, I’m inclined to agree that is true, but if there is more than one kind of hardware in more than one country…;
• Developing cross-platform software is truly a tedious and labor-intensive undertaking. You need to go through numerous cycles and the skills and knowledge of the programmer (or team) have to wrap the problem fully. In other words, not only is it annoying and time-consuming, but it requires a larger initial investment as well;
• If you’ve really decided to develop software for more than one device and country and you don’t have a team of savage, brilliant workaholics ready to forsake their private lives and families, then I would advise you to choose machine-independent software. In the long run, the odds (in terms of time, stress and ultimately money) stack in its favor;
• If you are on a modest budget and are just entering a given market (for example, you’ve been contracted to develop software for a restaurant which will work with a predetermined, specific kind of device) you may consider machine-dependent software but do keep in mind, your suffering will begin with the next client. At the end, if you value income and the future, sooner or later you will arrive at the idea of a separate control module for your devices;
• If you have a client who just needs a program or library for a small device, or especially if there already is an order for several thousand such devices pending, don’t waste his time, complete the order as fast as possible and give him device-dependent software:
  • First of all, both of you will finish the job and you won’t lose the order (business is money);
  • Second, if you’ve indeed explained to them that there is the option of machine-independent software and its pros and cons, you will have acted in a truly fair manner. If the businessman ends up choosing quick money (they like to do that), you will go to bed with your mind at ease;
• If you already have all the options developed and you just propose them to the client, that’s the apex, which aside from everything else brings satisfaction to all parties. In every case where I’ve been able to suggest all options and feel the customer’s satisfaction, I’ve felt the gratification of a job well done. If you are lucky and the customer mentions how bad the competition performed... that’s when you’ll get what I’m talking about. Anyhow, this is the best possible outcome, as it allows the customer to choose, and we people love choosing, even if we end up making the wrong choose.

 

Always be honest when asked about the possible options. All too often you may not be aware of the person’s capabilities in terms of time, money and desire for development. Let the other party evaluate and choose (unless you’ve been asked or paid for your opinion). If you’ve been frank, should the customer make a wrong decision given the present circumstances, then that person will have been left with a good impression of you and will seek out your services again. Whether it’s a joint venture or intracompany project, to me it is the right approach. Over the years I’ve been witness to many attempts in the trade to create software which binds the client with constant extra reworks and revisions (paid) and yes, that often works. The truth is that in this case the customer will leave you as soon as the first opportunity presents itself.

To me personally, when choosing how to go about something, in almost all cases the answer lies in the questions you asked the customer or yourself. The right questions lead to the right answers. Should you come to believe that either kind of software is superior to the other and you know better than your client what’s best for him… Well, I could argue on that topic over a beer, but here I’ll look more into technology discussions.

 

---