About the practice
A company organised around careful engineering.
DOG AND JONES LTD is a software engineering company. The work of the company is to understand a problem precisely enough that the software written for it stays useful once the initial enthusiasm has passed.
This page describes how the company thinks and works. It contains no claims that cannot be checked against the work itself. Where a statement is a commitment rather than a description, it is written as a commitment.
01 / Purpose
Why the company exists
A great deal of business software is written quickly and maintained reluctantly. The result is familiar: systems that work but cannot be touched, integrations that break silently, and organisations that grow afraid of their own tools.
The purpose of this practice is to produce the opposite outcome — software that can be changed by someone who did not write it, without drama and without archaeology. That objective shapes every other decision described on this page, from how estimates are given to how code is structured.
02 / Principles
The principles we work by
- Say what is known
- Estimates, risks and unknowns are stated plainly. An uncertain answer described as uncertain is more useful than a confident answer that turns out to be wrong.
- Prefer the smaller solution
- Where two approaches produce the same outcome, the one with fewer moving parts is chosen, even when the larger one is more interesting to build.
- Leave things understandable
- Work is finished when someone else could take it over. Until then it is in progress, whatever the feature list says.
- Respect existing systems
- Software that is already running is carrying real weight. It is changed carefully and replaced only for reasons that can be explained.
03 / Working approach
How an engagement is actually run.
Work begins with reading and questions rather than code. We want to see the process the software is meant to support, the records it will handle and the points where the current arrangement causes friction. Only then is a technical shape proposed.
Implementation proceeds in increments small enough to be reviewed in a sitting. Each increment is intended to leave the system in a working state, so that a pause in the engagement never leaves a half-finished feature in production.
Scope is treated as a living agreement. When new information makes an earlier plan wrong, the plan is changed openly rather than absorbed quietly into the schedule.
04 / Mindset
The engineering mindset
An engineering mindset means treating a system as something with properties that can be reasoned about, rather than a collection of features that happen to run. Before a change is made we try to describe what the system currently guarantees, what the change will alter about those guarantees, and what would tell us the change had gone wrong.
It also means accepting constraints honestly. Time, budget and existing architecture all limit what is sensible; pretending otherwise produces work that has to be undone. Where a constraint makes a requested outcome unwise, we say so and describe what could be achieved instead.
Finally, it means curiosity about failure. When something breaks, the interesting question is not who caused it but what allowed it to reach production unnoticed, and what would catch it next time.
05 / Quality
Quality standards
- Automated verification
- Critical behaviour is covered by tests that run on every change. Test coverage is directed at consequence rather than at a percentage.
- Peer review
- Every change is read by another person before it is merged, with attention to clarity and failure handling as well as correctness.
- Accessibility and responsiveness
- Interfaces are checked with the keyboard, at small screen sizes and for contrast, because these are requirements rather than refinements.
- Documentation as deliverable
- Setup instructions, architectural notes and known limitations are maintained alongside the code, not written at the end from memory.
06 / Communication
Communication philosophy.
We write things down. Decisions, assumptions, trade-offs and open questions are recorded where the client can read them, because a shared written record is the only version of a conversation that survives.
Technical explanations are given in language that a non-specialist can act on. If a recommendation cannot be explained without jargon, that is usually a sign the reasoning is not yet clear enough to be trusted.
Bad news is delivered early. A delay reported at the moment it becomes likely is a manageable problem; the same delay reported at the deadline is a broken commitment.
07 / Responsibility
Responsible technology approach
Software has effects beyond the feature it implements. It collects information about people, it shapes how staff spend their day, and it continues to consume attention and resources long after it is delivered. We try to keep those effects in view while decisions are still reversible.
In practice this means asking whether a piece of data needs to be collected at all, declining patterns designed to pressure or mislead users, considering people who rely on assistive technology as ordinary users rather than an edge case, and being straightforward about what a system cannot do.
It also means being willing to advise against building something. If the honest answer is that a client's problem does not require custom software, that is the answer we will give.
08 / Details
Company contact details
Written enquiries are welcome. Contact guidance, including what to include in a first message, is published at dogjonesco.com/contacts.
- Registered name
- DOG AND JONES LTD
- [email protected]
- Domain
- dogjonesco.com