Warning: this post contains some information regarding my job which may be considered "sensitive", though is not contract-violating in any nature. Recently a handful of bloggers have had their jobs taken from them simply by venting about work on their blog. In truth, the reasons they were fired typically involved citing names or exacting descriptions of their coworkers, followed by stating inappropriate things about them. Be it known that my aim in this blog is not to critique any individual, but rather the industry I work in, and a specific product with which I am dissatisfied.
The shipping industry, from a software perspective, is similar to many others. Like the health and oil industries, most companies are forced to work with the corporate titans to complete their jobs. In the software case, the last step of the shipment process is to transfer some definition of an order to UPS, USPS, FedEx, DHL, or any other large-name package carrier in order to get the "widgets" (as we so lovingly call them) delivered to their destinations. The definition of an order for any particular shipping carrier may vary, but much of the data is standardized at this point in time. However, like the oil and health industries, the method of storing and manipulating this data varies wildly from company to company.
Your basic definition of an order is one which contains a unique order number, a billing address, a shipping address, and a list of items to be shipped with their respective part numbers and other relevant information. Typically there are other pieces of data made available as well, such as the billed ship cost (useful with offers of flat-rate shipping), discount rate/percentage, shipping conditions (CoD, residential indicator, additional handling, etc.) and frequently more detailed data such as the customer number and possibly payment information. This data, while superfluous to the actual process of shipping the order, is occasionally useful to companies who want to do basic accounting or use the order data for statistical purposes.
Because there is frequently more data to an order than just that which pertains to shipping, more than just a handful of companies have sprung from the internet which provide full-scale "order management" solutions. Off the top of my head, names like MonsterCommerce, OrderMotion, NetSuite, and Yahoo! Small Business come to mind. These eCommerce solutions provide varying ways of importing, storing, displaying, and retrieving the data, and some are clearly better than others, and which ones are better depends on whether your perspective is that of a purchasing consumer or a developer. But I digress, for the moment.
The difficulty of creating shipping software comes in two forms: firstly, you must be able to successfully import and export data when interacting with a particular order management
system, and secondly you must interact with the carrier with which you are trying to ship the orders. Because the shipping carriers are used by so many thousands of companies, the methods for interacting with them are very standard and well-documented. As a result, the truly difficult aspect of the job is working with the order management systems.
Most order management systems provide the ability for clients to export and import data via a standard flat-file format, such as CSV, or XML. Frequently, order management systems provide direct methods of interaction which allow the developer to force fewer steps upon the user to ship their data. Such methods tend to allow the shipping software to directly communicate with the order management system, using a protocol like WebServices or ODBC. While ODBC tends to involve direct database queries, WebServices tend to operate using SOAP, which encodes and decodes objects into well-defined XML for language independence.
The Official NetSuite Rant
While I told myself at the advent of writing this post that I would not rag on NetSuite, I've decided to change my mind. Forgive me for lashing out as such.
Some companies, such as NetSuite, take management systems to the "next level" and attempt to produce company-wide management software which allows users to manage their accounting, orders, shipping, personnel, and funds from a single location. As one might expect, these products try so hard to accomplish everything at once, that they can fail at accomplishing any one thing well. The sad truth with products like this is that multiple development teams are required to maintain and build on the project, and metaphorically speaking the left hand has no communication with the right.
NetSuite, for customers, is likely not a bad product to work with. It has many customer-friendly features such as auto-emailing, partial order fulfillment, and online tracking. But for developers, it is a horrific black hole which will consume your man-hours and finances just to keep the product functioning. NetSuite is particularly bad at breaking version compatibility and tries to provide too many features. Many of the account-wide features/preferences within NetSuite inexplicably require or are mutually-exclusive with others, and create strange permissions or rule-breaking problems when attempting to manipulate records programmatically via server-side scripts or WebServices.
NetSuite's idealistic "golden ticket" for its customers is its ability to customize any form, field, or record in just about any way the user can imagine. Custom records and fields in NetSuite are treated as first-class citizens by the browser GUI, and can be intermingled and interchanged at will with very simple-to-use AJAX controls. The NetSuite product itself is truly a marvel, both impressive both in form and style; as stated by someone who despises the product. The truth is, if NetSuite did not attempt to integrate or "play with others" in any way, I doubt there would be many complaints to hold against them.
In the past two years working my current developer contract, I have had the pleasure of working with NetSuite almost constantly. Their development team manages to break version compatibility no less than four times a year (on average) for integration partners. I've had required fields become read-only because they were "loop holes", and I've had previously-working code completely break due to the beta of the next version having an additional required field. Of the numerous NetSuite clients we have had, most have differing "versions" of the NetSuite web application, which has convinced me that each NetSuite customer has an account on either a separate machine, or with a separate database structure. As a result, code which works flawlessly for our developer account or a particular customer may fail for everyone else using NetSuite. This version instability applies to the server-side scripts as well as the WebServies API, and almost always requries several hours of updating to bring the product solution back to a working state.
I suppose my last rant against NetSuite is its speed. The NetSuite GUI itself is a hulking AJAX beast with scripts which must load each and every time a new page, form, or record is loaded. If you wish to export data to XML or CSV, the data request goes into a queue which may take up to a half hour during peak times, regardless of the size of the result set. Also, via WebServices, any simple single request may take up to 5 minutes, and the data returned usually contains references ID's to related records, instead of including the full transaction information that you may need. Searching for records can take hours, and appears to be linear in time as compared with the size of your database.
NetSuite is likely a fine solution for small- and mid-sized companies. For large-scale shippers (more than 100 transactions a day) I highly recommend against NetSuite, as I know of a handful of NetSuite clients who process several thousand orders per day, taking hours upon hours to import their data into 3rd party applications. People at these companies have been fired for choosing NetSuite as their management system after the difficulties it has inflicted upon them, and that is a fact which should be taken lightly.