Systematic vs. Opportunistic Programming
In any large organization whose business is not software development, we can find two types of product development philosophies. The business side of the enterprise will see an opportunity to automate, streamline, performance boosting opportunity and would like a quick and dirty way of converting into a software. For example, in one of my client organizations, the claims processing division uses Access to automate Excel spreadsheets or manual work that is shared by small group of people. While this is great start for the benefiting group, it creates a maintenance and auditing nightmare for the IT department.
Hence, the IT department which, most of the times, reports to CTO, profess systematic programming. In this approach, the application is developed methodically and involves analysts, developers, managers, quality assurance, security, technical writers, disaster recovery, release management, and post implementation support plans.
The business will resist this approach because it bloats cost and extends product delivery time. Almost all the big companies will have some tension as a result of this contention.
A successful software architect need to look for patterns among these ‘quick hit’ software and try to create a sustainable product that can replace many of them when the business comes to IT for expanding the scope of one or more of such software.