That's for business but I think it applies to individuals as well. You're much more adaptable than software. Pick the thing closest to what you want and change how you work to fit the software.
Some companies have the skill and desire to build their own tools over our products so they can use their pre-existing workflows, but inevitably the abstractions start to leak and they almost always end up hiring us to train them on how to use the tool the way it was meant to be used.
More frequently than you could imagine, people and organizations jump to how they are going to implement something before they define what they want to implement. And when the effort fails, the technology is blamed and they start all over again.
They end up finding that garbage in = garbage out
I’m not sure I agree. I think good tools represent the problem space well, and provide powerful ways of manipulating/interacting with it. That may or may not be what people are already doing.
I’d say solving a problem well is orthogonal to what people are actually doing.
In the end every quirky thing you do means more on the job training for all new employees. If you take quirky too far, then you can’t hire new senior talent (everyone starts as a noob). And it may be very uncomfortable to look at, but you need to think hard about who benefits by having things be this way. It’s not the company, and probably not the team. It’s a couple of people and likely also their manager.
When you adopt a tool you adapt your workflow to its limitations.
on edit: obviously this is an "ideally speaking" type situation.
- When you write a tool without knowing exactly what is a beneficial workflow, and this imperfect, probably under-documented and under-tested tool must be maintained over the long term.
- When you adopt a tool - trusting that its developers know what a beneficial workflow is - and it doesn't suit your workflow, or skews your workflow unnecessarily, where you have to bend over backwards to suit the tool. It can add inefficiencies and cost of time/effort, that might not be worth it - but, once adopted, you could be stuck with it over the long term.
---
The posted article argues for the advantages of "homebrewed tools". The main point being, the priority and emphasis on the workflow itself, which the tools should support.
> I can build the tools that exactly conform to my workflows, rather than constructing my workflows around the tools available to me.
> ..Tools you build yourself can grow and change as your workflow changes over time.
> This is typical of the way I discover my workflows. I start with a minimal, bare-bones solution, and try to pick up on patterns and tricks I create for myself. And then I encode those patterns and tricks into the tools over time.
In my experience, I've found this approach to result in simpler systems that are easier to understand in a sitting. When it goes wrong, it can be adjusted right there in the tool.
And, in general, I feel that when things go wrong with an established, community standard tool, it's more painful to work around it since, usually, it's not easy or possible to change the tool to fit your ideal workflow.
---
There's something to be said for community-developed and supported tools, with detailed documentation and a crowd of people using it in production, essentially testing every nook and cranny of the tool.
I suppose only experience can truly distinguish when one approach is better than the other, in a given context.
½ of the subscription including your time, or no?
I spoke with there legal team and turns out they didn't really need a legally binding signature. New system does everything they actually needed, without any real reoccurring costs.
While hiking around Iceland, for example, one should adopt established tools and methods, and adapt to them. No one's workflow can ever grow to accommodate that level of embedded efficiency and safety.
Real change in business requires adopting new processes. I just helped a small business shift from a paper driven workflow to electronic. Adapting their workflow to fit established tools was less work than doing nothing, less effort than their existing process; they doubled their output literally overnight. We'd have been fools to try to adapt a tool they'd never used or heard of before to look like their paperflow.
In the short term, perhaps, but at what cost in the long-run? We end up with channels of accepted behavior dictated, undemocratically, by software teams.