Frequently Asked Questions (FAQ)

Table of Contents

Introduction

Terminology

Assignment

Project

Product

Report

Review

Reviewer

Symbiosis

Frequently Asked Questions (FAQ)

Digital Material

How do we send you digital material?

How do you store our digital material?

How do you erase our digital material at the end of an assignment?

Physical Material

How do you store our physical material?

How do you handle physical material after the end of the assignment?

Source Code

Do you need to be able to compile and/or build our source code?

Do you need access to the product's entire source base?

Do you need access to our revision control system?

Introduction

On this page you'll find a list of commonly asked questions to Symbiosis Software.

Terminology

We use a fairly standard set of terms in our business that may require a bit of explanation.

Assignment

An assignment is the process of reviewing some source code or some documentation. An assignment only covers a single review and if material is resubmitted for review after it has been reviewed before, it is a new assignment.

Depending upon the nature of your product, you may require us to do only one assigment or perhaps dozens of them. It is something that you decide, we simply perform the task of objectively reviewing your material for design flaws, code flaws, writing flaws, and so on.

Crucial to the concept of an assignment is that we do not keep copies of material across two assignments unless you instruct us to do so. Once an assignment has been completed, we destroy the digital material (software, PDF files, etc.) and return the physical material (printed books, discs, hardware) and so on to you so that you know for sure that we do not keep old copies of your project lying around. Your material is of no use to us as our only business is to review customers' material and ensure it is improved as much as at all possible.

Project

A project is a well-defined and mostly independent subset of a given product. For instance, a compiler has a command-line parser, a lexer, a parser, a semantic checker, a code generator, an optimizer, and an output file writer. Each of those things are independent projects that may or may not consist of a number of other projects.

Product

A product that has been or is being developed by some entity somewhere. This could be an application, a book, or a server. It doesn't really matter what it is, the term simply refers to the sum total of projects that make up a product. For instance, most software products consist of several projects: A set of software components each of which is a project in its own right, a manual, and perhaps some physical media used to ship the product.

Report

The final PDF file that documents the result of the review. We use PDF as this is a very commonly used and standardized format.

If you prefer to get a Microsoft Word file, you can tells us that when you submit material to us.

Review

A review of something with the objective of controlling the quality of and identifiying weaknesses in.

Reviewer

A person who performs a review. In the software industry, this should generally be an external consultant.

The consultant must always work under a personal non-disclosure agreement to guard against unwanted disclosure of material.

Symbiosis

Symbiosis means that two independent and often very different forms of life co-exist in such a way that both benefit from the co-existence. Our name reflect our view that we are an external, independent, and mostly objective extension of your company.

Ideal symbiosis goes both ways: We love your comments and feedback as much as we hope you love our reports.

Frequently Asked Questions (FAQ)

This chapter lists various questions and their answers that may be of relevance to you.

Digital Material

This section contains questions related to digital material (computer files) that you submit to us.

How do we send you digital material?

The simplest way is to follow these steps:

  1. Download and install 7-Zip on your computer (7-Zip supports Unicode on all supported platforms).
  2. Download and install AES Crypt on your computer (this is an AES encryption program).
  3. Create a 7-Zip archive with all of the digital material that you want to submit to us.
  4. (Change to the directory containing the digital material and execute the command: 7z a -r r:\archive.7z *)
  5. Create a 64 character long random password using Secure Password Generator or a similar service.
  6. Encrypt the 7-Zip archive using AES Crypt and the 64 character password as the encryption key.
  7. (Execute the command: aescrypt -e -p password -o archive.7z.aes archive.7z)
  8. Send the encrypted 7-Zip archive (archive.7z.aes) to our email address.
  9. Send us the password via Skype or a text message.

How do you store our digital material?

All digital material is stored in a strongly encrypted VeraCrypt container that only the consultant assigned to the project has access to. The container uses 256-bit AES encryption or stronger. The password to the VeraCrypt container is always a random 64 character password generated using KeePass v2.x.

In addition to these security measures, the container always uses at least one key file that is not stored in Dropbox but is instead backed up in AES encrypted form to an external server.

All VeraCrypt containers are stored in a Dropbox folder, which is automatically and frequently replicated to Dropbox's servers so that we are complete sure that no loss of data will occur in our end, most noticably that the report is always tucked away safely on the Internet so that we don't lose precious hours on a simple technical error.

Notice:
The local key files are not stored in Dropbox so nobody at Dropbox (not even the NSA) can access the material inside.

How do you erase our digital material at the end of an assignment?

We erase your digital material using three steps:

  1. We first erase the local VeraCrypt container in the Dropbox folder.
  2. We then erase the Dropbox history in the cloud so that nobody can recreate the file any longer.
  3. Finally, we permanently erase the password used to access the VeraCrypt container (it is stored in a KeePass v2.x database).

The last step ensures that even if a VeraCrypt container has survived somehow, perhaps through a misconfigured backup system, we cannot access the content anymore.

The above setup ensures that no unauthorized personnel can ever access your material in our end.

Physical Material

This section contains questions related to the physical material that you perhaps have sent to us.

How do you store our physical material?

Currently it is stored in our office. We have no special safety routines as of yet because this kind of material is very rare.

How do you handle physical material after the end of the assignment?

We return it to you unless you request that we simply destroy it.

We prefer to return your material to you because experiences from Iraq shows that given time and resources, even shredded documents can be reassembled into a coherent whole. You might also want to reuse the materials somehow.

Source Code

This section is about source code and what we need from you in that regard.

Do you need to be able to compile and/or build our source code?

Generally speaking, no, we don't need to be able to compile and/or build your source code. We don't do debugging and actual error correction. Instead, we proof-read the source code and point out a number of problems and likely causes of bugs. We don't use automatic tools to analyze the source code (if we did, you wouldn't be needing us) for which reason it is generally unimportant if we can compile and/or build the source code.

We do prefer, though, that the project is buildable in your end so that we don't have to work with the added complexity of code that cannot be compiled and/or built.

Notice:
If you want us to do actual rewriting of code, we generally prefer that we can build at least the project that contains the code.

Do you need access to the product's entire source base?

We generally prefer to have access to as little code as possible. This because of security implications and more importantly that we prefer to reduce the task at hand to the minimum possible so that we don't waste our time navigating your source code.

The only thing we do need is that we have access to "most" definitions that are used by the source code. For instance, it is very hard to review code that uses complex, parameterized macros extensively if we do not know the definitions of these macros. On the other hand, simple enumerations and defined constants are not so important to us as we don't need to know their precise values.

We typically expect to be given ten to fifty source files out of a set of perhaps thousands of source files.

Ultimately, you decide what we get access to but the more relevant and the less files it spans, the better our report.

Do you need access to our revision control system?

We definitely prefer to not have access to your revision control system. It has only exceedingly little value for us and it security implications, even if we have only read-only access, are not good. The less material we have, the smaller the task ahead of us and the less likelihood that we get hacked and inadvertently end up leaking important material.

The larger the data set we are given to begin with, the less concise and precise the final report will be. There's no point in us learning how you build your product and the vast tree of projects in your product is generally of no use to us.

Imagine you were handed 20,000 files. How much do you think you'd accomplish in ten hours? And then imagine that you are given, say, two source files. Then how much do you imagine you could accomplish in ten hours?

Our task is to study your code and provide both high-level and low-level guidance on how you can greatly improve your code. Our task is not to debug nor correct errors in your code. If we find problematic code that likely contains one or more errors, we'll report it, but generally you are yourself responsible for fixing any errors that we discover.

The main purpose of an external code review is to have fresh, objective eyes see what you or your software developers do not see.

Our greatest value is that we are working outside your organization so that we are not bound by the intellectual climate in your organization and nor by personal considerations. We strive to be efficent, objective, and usable!