Coding for Business Applications: How Size Matters
The prevalence of computer software in nearly every aspect of business means that we are more dependent than ever on technology, from simple applications to enterprise-level solutions. Many businesses have invested significant resources - not just money, but time, organizational structure, and operations - into developing software that is top-quality in terms of its degree of dependability and usefulness, among other metrics. The size of the software application being developed does matter, because the amount of code in a given project has incredibly far-reaching effects.
Large-scale applications require more code; generally speaking, the more work the software needs to do, the more code will be required to achieve it. Elaborately-coded platforms can be unwieldy, but they need to maintain some flexibility in order to adjust to the changing dynamics of the organization. Big projects often mean that there will be more people providing requirements, and typically, very few of those individuals will have technical knowledge. When everyone wants something different from the software, it can be very difficult for the developer to ensure that the code stays clean. For example, members of the sales team may want a particular application to integrate a CRM (Customer Relationship Management) portal that will allow them to track visits and calls to potential and existing clients, while the accounting department demands that the software integrate with or replace their existing accounting solution. Requirements that spiral out of control in the design phase require more code, which raises the following issues:
- Budget: Not only do development expenses increase, the ensuing costs for maintenance, updates, and revisions quickly rise.
- Delivery Times: Since more code means more time, it can be tough to meet launch deadlines, which can impact other business operations, such as scheduled training. Software projects can also end up overlapping one another, overwhelming developers and frustrating stakeholders.
- Documentation, Configuration Data, and Program Guides: When there's more code, more needs to be written about that code, and again, this requires considerable resources if the application is large. Besides the actual documentation, there needs to be someone to manage it, train on it, etc., and this requires time and effort on the part of personnel.
- Security: Larger applications that require more code usually mean more users, and that fact alone can make the software extremely vulnerable. The recent Target security breach may have been inadvertently caused by an outside vendor.
- Change Management: Sure, it's great to have an integrated platform, but when one piece of code is being revised and breaks down, what happens to the rest of the software? An elaborate process for damage control is an absolute necessity with large-scale projects, and resources need to be allocated to that endeavor. Systems resources may also be impacted when changes are made to the existing application, so they need to be considered as well.
If any of these issues are not proactively addressed by the company investing in the development of the software, the quality and dependability of the application could be adversely affected.
Of course, if the amount of code in an application is insufficient, such that functionality, performance, dependability, and/or usability are compromised, the entire project could be a complete waste of money, which is bad for any business. For example, if the application is supposed to work on mobile devices and doesn't, the intended users could shy away from it, rendering it useless. There are also often political implications for the individual or team spearheading the software, as well as for the developers. Championing a project that doesn't perform can have severe repercussions in the workplace, particularly if the software was needed to solve a core business problem and/or consumed significant time, energy, and money.