AeSoftwareDevPhilosophy

1 Nov 2005

I believe strongly that a significant component of the “low software quality” problem-space is failure to understand and appropriately respond to product requirements. In my opinion, it is a given that if you cannot determine or express the product requirements you cannot fulfill them with the product. In order to make a dent in this problem I have bought the domain “OpenRequirements.org” and plan to develop an open-source requirements definition system.

In my scheme, all requirements can be enumerated unambiguously; can have “verifiers” (manual or automated) created for them permitting automated and model-based verification. I also believe that open-source concepts need to be extended both into QA and software specification practices. OpenRequirements.org is intended to address both. Briefly, if specifications are not directly verifiable they are not adequate, and the solution must cover both expression and verification of the design in order to be an end-to-end solution.

I’m passionate about making CAD and graphics software better, and believe that consortia like the Open Design Alliance and IntelliCAD Technology Consortium are acting as key forces in the industry helping to drive CAD innovation. The innovation of hybridizing Open Source methodologies, non-profit business practices and the best of commercial software engineering practices provides a glimpse into the future of software development. I am excited to be aligned with these organizations and to help them compete. I believe their primary competition is not other CAD companies but the high cost of CAD, both in direct monetary terms and in terms of lack of innovation, bad usability, and lack of opportunity for vertical application vendors.

I believe a good way to think about how open-source methods and ideas can improve commercial software quality is that they can provide a coping strategy for the following large challenges

Challenge statement	Problem discussion	How open source-like strategies can address challenge
It isn’t possible to specify all features of the product	While this is technically true, this is not a valid excuse! Not having a specification authoring tool which can be shared across the proper base of stake holders guarantees that the product will be inadequately specified.	Opening the specification process up to a wider audience means requirements can be expressed clearly, and eventually satisfied.
It isn’t possible to test every feature of the product	his is a factual statement, but let’s look further. It is clearly impossible to verify that requirements have been satisfied if they have not been defined clearly!	Opening testing (what I prefer to call “requirements verification”) to a wider audience means that more testing is done and features upon which others depend can be tested by those who understand the dependencies.
Quality Assurance is too expensive	In addition to commonly understood aspects of low software quality (bugs, crashes, etc) consider the deeper problem… software which fails to fulfill the requirements of its users. Software which is ill-suited to solving the users needs is a far deeper quality problem which our industry seems incapable of addressing.	The only solution to this problem is to build tools and systems which actually allows users desires to be enumerated, aggregated and acted upon.
We have no way of finding out which requirements our users will pay us to fulfill	This issue lies at the heart of the software quality quagmire. Some have approached this as a marketing problem (which it is), but have never attempted a technical solution.	Creating tools which allow requirements to be expressed unambiguously by those who understand them will lead to higher revenue and customer satisfaction. Using “marketplace of ideas” concepts to rank and de-conflict requirements can practically guide a software development team (similar to how Amazon.com users rank books, or Ebay rates buyers/sellers.)