How Programming Accidentally Runs Companies
And without proper recognition, software development can accidentally slide into the driver's seat. When does this happen? When developers start making decisions and recommendations that stray too far from a company's vision.
Over the past decade the software development industry has witnessed a level of ubiquity in business that has changed the way companies approach problems. Technology departments are now found in most businesses and programming teams are no longer relegated to "technology companies." This is due in part by the fast paced, pervasive role technology has played. Although taking the leap into custom development might have been an accidental or imprudent decision, it's essential to recognize the benefits and potential pitfalls. Having a programming team introduces new challenges and sometimes a company gets more than it bargained for.
As software grows in complexity it becomes increasingly difficult to manage, maintain, build, and scale. No development group is immune to these conversations. Every programming team crosses these roads as they attempt to meet the demands of business. Sometimes this can lead to inadvertent back-seat driving of a company. And without proper recognition, software development can accidentally slide into the driver's seat. When does this happen? When developers start making decisions and recommendations that stray too far from a company's vision. These decisions can range from using risky or unproven techniques to extensive refactoring that leads to missed deadlines or a loss in profitability.
How can developers avoid this? By being good stewards of their employers first. Although programmers are hired for their ability and expertise, they should maintain an advisory role. In this role, it's important to provide a variety of options for each request or problem. This includes providing the amount of time and effort required along with the risks for each option. Be sure to allocate enough time to investigate and vet each recommendation before introducing them.
This advisory role is not meant to exclude software decisions from a company's overall vision or road-map. Software teams should remain a key member in setting the overall vision. This change in approach helps find a better balance and bridge the gap between the "mysterious world of technology" and business. Being a good steward and technology advocate will result in solutions that find pragmatic compromises between a company's vision and programming desires. For developers, this might require completing the slightly "uglier," "harder," or "incomplete" solution in an effort to maintain forward progress. This moves both the business and programming forward without leaving the other behind.