If You have to ask the Price, you need a bigger Budget
Sometimes we respond to the emails we get directly and privately because it just seems more appropriate. At other times we share our responses because we believe that our response fit some general case of potential questions or potential emails. So in the interest of time and effort we share our response to particular emails.We were recently questioned about the practicality of formal software development methods, formal languages, and specification languages as they apply to small-to-medium software development efforts in general and small-to-medium parallel programming efforts in particular. In fact, we were accused of being a little preachy and unrealistic, and that we were making assumptions about the development resources available to any given organization.
We always enjoy this type of email and at times we've answered them privately and then some pretty useful exchanges ensue. But today we would just like to share our general position on the matter. We realize there is all sorts of software cobbling going on out there with lots of the cobbling done by end-users who are technically savvy but with no formal training, education, or apprenticeships. We are personally aware of many, many small-to-medium size organizations using anyone in their organization that seems to have a knack at getting something done on the computer, as the defacto development person or group. We find finance people doubling as developers, administrative assistants doubling as web programmers, network engineers doubling as software engineers, etc. We can also appreciate some of the reasoning behind these relationships of convenience, and we understand the cost savings to the organization. We get the whole get-er-done mentality; do-it-yourself lawyering, self-diagnosing using doctor-on-the-web, making additions to the home with the help of a DVD and a visit to the Home depot. We get that. But we can't let convenience, cost savings, and as-long-as-it-works-for-now approaches violate or dictate the basic principles of software engineering.
There is a reason why engineering degrees, med school, law school, etc., take so much time. These things require highly specialized knowledge, education, training, vernacular and skill set. The student and apprentice go through years of exacting education and specialized training. One of the reasons this is necessary because the professionals that are released into society from these areas have the potential to directly affect the public safety and the good of the commonwealth. We want our buildings, bridges, roads, and amusement parks to be safe and we trust our engineers have the knowledge and the skill set to make it so. We want our medical practitioners to hold all life precious and sacred and we want them to have the requisite knowledge and skill set to preserve life and maintain health at all costs. From me and Tracey's perspective software engineering also demands this same level of responsibility to the public. You better believe we make assumptions about development resources! Here are some of them:
We assume if you are engaging in a software development effort, that you will have access to professional software engineers and developers. And that these engineers and developers are versed in the basics of software engineering and computer science and have formal training, education, or apprenticeships. We assume that your development effort will adopt one or more formal software development life cycle models. We assume that your organization either has the time or will make the time for the software engineers to effectively do their work. We assume that you can afford the software development effort. If the software development effort is going to produce software that is unsafe, unreliable, or incorrect, it's better not to produce any software at all. That's the long-winded answer. And here's the short version answer to one of our more recent and critical emails; if you can't afford to do it right, then you can't afford to do it at all. Our assumption is that you want to do it right and you want to know how to go about doing it right. Formal languages and specifications to follow ...