How we develop the Library and App

Write down what you’re building

Each project starts from its intended result: who will use it, what it must do and how it will be examined. The person directing the work accepts that basis. The Library’s requirements and the App’s requirements have separate homes.

Give each contribution an owner

Divide the work into useful contributions. Each needs a purpose, expected outputs and conditions for use. Its owner carries it through implementation, review and repair. A coordinating agent keeps the combined result in view.

The Library’s first formal project had five packages and seven deliverables. Their scopes covered finding material, maintaining it, organizing execution, examining coherence and supporting reuse. The folders made the responsibilities visible; the work had to establish the result.

Follow the actual relationships

Independent work can proceed together. Where one contribution needs another, ask what it needs and when. A usable interface can let work proceed before the whole supplying component is finished. An unresolved premise can hold one calculation while other work continues.

Examine what the checks establish

A draft Library explanation described a format distinction as historical. Review of an actual caller showed that current code still depended on it. The team corrected the explanation before integration. Agreement among the draft documents would not have found that error.

In App v4, headless setup tests passed while a desktop attempt failed. A later native test established setup, saving and normal quit for an identified candidate. That was a useful result. It did not establish the whole App’s release readiness.

Bring the work to a decision

The Library’s development reviews examined what dependent work could rely on and what still needed attention. Final acceptance and release followed examination of the assembled result. The published archive identifies the source supplied to readers; its checks do not qualify every possible use.

Let experience change the method

During Library development, the owner found that contributions were returning before the connected work was carried through. Changing the size of the assignment let one owner carry the explanation, publication and affected instructions through together.

Chirality in Practice examines this undertaking, including what the record supports and what remains untested. The thesis also examines App redevelopment and SWBPIPE as application cases.