Modern Software Development Methodologies

Traditionally, the big argument against in-house development is the cost to develop, then maintain, it. But, with the ability to scale endlessly using cloud infrastructure, and some discipline in the software development cycles, the time to implement can be equal to, possibly better than the difficult large scale project called, tongue in cheek, “software implementation.” Support is also becoming easier for in-house developed software; the DevOps model forces everyone to attack weaknesses and write functional, maintainable code. It makes sense to keep support within the company if the software is part of the business model. An in-house support team will react better and faster, and have more empathy for the users and customers, than any third party software company’s service desk. Package software still has a place in a company’s portfolio. Non-mission-critical systems or those that have no impact on the business model are well suited for packages. Most companies already made heavy investments in financial and other modules within ERP, and it would be a waste to try to rewrite those in-house. Equally, there are plenty of financial and HR packages available, email options and so on. Packaged software’s big weakness is the reliance on “versions.” Software companies work diligently to produce short-lived new versions with many features, functions and performance improvements versus the prior model. As soon as customers get the new version, they begin to modify it to meet their business needs. Modifications away from the standard package are crucial for a company – their unique business model can never be 100 percent reflected in software designed to work in a standardized way across many diverse enterprises. However, any customization away from the standard package makes it very expensive to move to the next version – the mapping exercise, both functionally and technically is time consuming, often requires expensive consultants and ultimately yields little value for the company. Bluntly, upgrades rarely have a positive ROI. Software companies are filled with people who write code – programmers, not operators. Software engineers are talented, smart people, but rarely have any of them worked in a factory, warehouse or logistics center. They simply haven’t experienced the world of manufacturing, distribution and logistics. At DSC, we believe that putting our operators, industrial engineers and software developers together overcomes this problem. Digitizing a business is an in-house activity. The speed we all need to react to customer demands won’t fit into the development cycle of a third party package. By building in-house, not only can we match the speed that customers require, we can also create exactly what the customer really wants. Iterative, agile approaches stress working with the customer to build something that meets their need; this makes us better – and hopefully more important – vendors in the eyes of our customers. Equally, controlling development in-house allows for experimentation; we can foster creativity, and then ask our customers if they see it as an advantage. This ability to react to customer requirements and also develop entirely new things for them suggests in-house development is the way to go. Where to start with in-house development? Start with your business model and the technology to support it. For logistics, that means transportation and warehouse management at the core. Is your software adaptable? Can you easily make modifications? Do you know when you have to upgrade your packaged software – when does your version stop being supported? Then talk to your IT team. They are likely bursting with ideas, just like your line managers and engineers. Sit down, have a candid conversation about how to support the changes you want. Most of all, be confident that your team knows your business and can deliver better than a remote software company can.