| Operating Systems: The Developer’s Perspective | | Print | |
|
CT: What choices do software developers have to make when they pick the platform their products will run on? Stephenson: The choices for a software development team are many. Each choice has an impact on speed of development, program performance, ownership costs, and user friendliness. Many people tend to think of the operating system in terms of what their prescription entry screen looks like. We often receive questions about whether we would recommend a UNIX system or a Windows system. Typically what our pharmacists are asking us is whether or not the screens are graphical with a modernized user interface. To provide the streamlined data screens and Windows abilities, you really get into the languages and database engines the pharmacy system is built on. The language is what allows the developer to create the program and control the user experience. The data base manager is a critical component. It may not sound glamorous, but in reality the database engine is responsible for the responsiveness of the system and the flexibility of sharing data with other applications. You could think of it in terms of owning a sports car with a high-performance engine, when you are driving down the street people notice the paint job and visual appeal of the car because they cannot see the engine. CT: How do these choices affect the developer? Stephenson: This is an interesting issue that we deal with constantly. As a software development company that has existed for more than two decades, we have to use toolsets that allow us to continue recruiting talented software developers as we grow our platforms. Using the same toolsets we used two decades ago would be nearly as limiting as operating on decades old hardware. On the other hand, completely re-developing new platforms typically produces new software without the features that we’ve added to our systems from the first time we ever received a phone-call from a pharmacist with a request for a new feature. When you completely recreate a platform, the cost is high in terms of retraining developers or recruiting developers and then teaching them about how their applications are required to work in the hands of pharmacy staff. In our case we were very fortunate in our selection of languages and database vendors. We have recently completed a process that allowed us to migrate our software into a touch-screen user interface and reduce the costs to our customers. The customer can see reduced costs from these decisions in a number of ways. Typically we have seen development companies in other industries charge very high upgrade costs on a recurring basis, and we have seen software products that had costly runtimes and database engines that were nearly as expensive as the application the user was purchasing. Another hidden element of user cost is when an application with a new interface does not provide proper functionality such as a field-proven inventory control system or accurate prescription pricing and claims processing system. CT: How do these choices affect the end user? Stephenson: Training is a cost, whether with your existing generation of employees or the next set of newly-hired technicians and pharmacists. Bad training can also represent a cost in terms of slower dispensing speed and further costs if the pharmacy owner or manager is either unable to identify the tools and reports necessary to maximize prescription margins and safety or is unable to keep them in the workflow because they aren’t easy to access. Most pharmacy owners are purchasing their new system intending to pay for the system with the new features and analysis that the system offers. If their training revolves around data entry and claim submission as the store goes live, the training process and the way the system presents features to the user can ensure that the management components and automated reports are operational and used regularly so that the owner receives a better return on investment. Our answer to this problem was to modernize the user interface so that the pharmacy and workflow screens were more intuitive. By building on-screen buttons sized for touch-screen, we believe that over the years technicians and pharmacists alike will be less likely to forget about a function key or command letter that actually had performance benefits to the user. The idea was not to water the system down by removing key-based shortcuts, but to enhance it by adding on-screen shortcuts. This means that the system is still as fast in the hands of a seasoned user, but easier to learn and operate for novices. So to us, our touch-screen GUI is about more than simply offering attractive prescription entry screens. CT: We've been talking about the paint on the sports car here, that is the user interface. How do your programming decisions support these choices you made? Stephenson: By initially choosing a toolset that provided constant modernization options, we were also able to protect our current customer base that operates thousands of text-based systems to manage their businesses today. By using the right development toolset, we have been able to preserve the UNIX application, and keep it up to date concurrent with the Windows version. Our runtime is smart enough to understand whether to present a graphical entry screen or a text based screen based upon the way we install the system. That means that an independent pharmacist who has been operating one version of the system is not facing a planned obsolescence in favor of a newer system and will continue to have all our newest features available as he upgrades. This allows our customer base to plan their system upgrades based upon their need rather than our timetable. |
