Notes tagged
principles
20 notes on principles. All notes.
A CRM and a task system are not the same thing
One is organised around a person outside the company, the other around work inside it. A builder needs both, and they should meet only at the crossing events.
How to choose construction software without regretting it
Most of these purchases fail in the evaluation, not in the product. Follow three real transactions end to end, then watch for the parallel register.
Getting your data back out
Every system ends. A report is not an export and an export is not a backup, and the difference decides what you are holding on the day you leave.
Ask to see the audit trail before you sign
Every vendor says the history is kept. The way to find out is to make a record, change it, cancel it, and ask to see that one record's history on screen.
How to test a "works offline" claim in ten minutes
Every vendor says the app works offline, and the word means four different things. A cheap phone in flight mode settles it faster than any meeting.
Approval chains worth asking about
Every vendor can draw a workflow diagram. The questions that separate a real approval system from a picture are about the cases nobody draws.
Keep your own copy
At final account the argument is settled by whoever can produce a dated document the other side cannot contradict. Usually that is the larger party.
How we find our own problems
Nothing here starts with a market report — it starts with hitting the same wall for the tenth time. Notice, build, keep alive, and why stage three decides it.
Why one person should never move the company's money
Two different people on every payment is not distrust. It is the cheapest control there is, and every convenience that erodes it erodes the whole thing.
Who is allowed to decide what
Most permission systems answer "what may this person see". The harder question is what they may decide, and organisations usually cannot state their own answer.
What an audit trail is actually for
Not catching thieves. An audit trail exists so that a decision made a year ago can be reconstructed, including by the person who made it and now has to defend it.
Append-only: why a correction should never overwrite
A record that can be edited answers only today's question. Adding a correcting entry instead costs one row and keeps the history that makes the number defensible.
Tamper-evident, not tamper-proof
You cannot stop somebody altering a copy of a document. You can make any alteration detectable, and that is a much more useful property than it sounds.
The machine proposes, a person decides
An automatic link that turns out wrong is not just an error. It is an error that looks like a record, and nobody reading it later can tell nothing was agreed.
The app should tell you why
A refusal with no reason, an empty screen with no cause, a score with no basis. Each teaches that the software is arbitrary, and arbitrary things get routed around.
A default is a decision somebody made once
Defaults are set in the abstract, by somebody not thinking about your case, and then apply for years without ever looking like a choice again.
Offline-first is a data decision, not a network one
Queueing requests is the easy part. Offline changes what a record means, because it was created by a device nobody was watching, at a time nobody can verify.
An alert that rings for everything is an alert nobody hears
Priority is the wrong axis, because everybody's work is important. Sort by what the message asks the reader to do, and there are only three answers.
A test that describes the code will defend a bug
A regression test anchored on how the code works, rather than on the rule it is meant to enforce, will guard a defect as loyally as a feature — and report green.
The gap you stopped noticing
Most broken things at work are not unsolved — they are worked around so smoothly nobody calls them broken. Breaking that habit is why BE Teck exists.