As with most involved processes, a person’s definition of software development typically depends on their experiences and level of involvement. Some argue that software development is art, others say it’s science and some say it’s engineering. Some maintain that it is a combination of the three while others suggest that the ‘craftsman’ or ‘artisan’ label is most appropriate. Whatever the definition should be, great developers can create spectacularly inadequate software and mediocre developers can create amazingly successful software. Software created by different teams to solve similar problems can often have wildly differing costs associated with development. These peculiarities exist primarily because key decisions about software development are not always made by the correct people in an organization.
Advances in software development over the past 30+ years include flowcharts, structured code, object oriented programming, reusable code, Web-based applications and agile software development–just to name a few. While these advances have indeed provided some incremental relief from the universal pains of software development, they have consistently served to prove one thing: There is no silver bullet. Developers feel the answers lie in better tools and programming techniques and better informed managers. Managers believe the solution involves better and more processes to run software development and developers who understand the business they are attempting to support. Both are somewhat correct.
Depending on which sources you subscribe to, most people seem to feel that software development is at best painful and in the worst cases, a failure, so it is no wonder they have little confidence in the outcome of software projects. I’ve witnessed large, successful, well-funded companies spend years launching colossal failures and I’ve seen small firms with limited resources create great successes. For those not close to software development, that can seem pretty random. With something so unpredictable, the less you invest on a gamble, the better. Following this logic, wary managers often feel that the single best way to spend less money on software is to spend less time. This is why managers are always pushing to limit time spent on software development and it’s why developers typically feel they aren’t given enough time to do their job well. Given a choice, few competent business people would choose speed over quality and accuracy of meeting business goals–if only they had more faith in the outcome.
Nonetheless, development tools are constantly improving, processes are getting better and success stories are being reported. My involvement in software development in Kansas City over the past nearly 20 years have offered me a unique perspective from experiences and observations in hands-on development, team management and product development areas. Via this blog, I’ll share these and other observations and look forward to others experiences as we all continue to work toward <more> perfect software development.