Friction Points

Having done a bit of project hopping in the last months, I came across some (potential) friction points that I thought were worth documenting. Things one may feel to have to fight against when working on a (client) project. That could be something that is always different between projects, and one always has to get used to how it’s done. Or it could be something that had been all the same for so many projects, until some odd one came about. It might have been on a brandnew project that you helped kick off, or maybe it was when you joined an ongoing project.

For a lot of problems or tasks, there is not the tool to use, or process to follow. But it certainly doesn’t make a lot of sense to have a dozen of tools or processes in use that all solve the same problem. You might want to review, assess, streamline and maybe even standardize one one or two, and clearly document them and actively share and curate useful resources in an ongoing basis.

So, let me start by sharing a list of potential friction points, some of which, I’m sure, you know too well:

• Local development: Looking at regular client projects, what is the recommended local development setup? How much of the setup is documented, or even scripted?
• Tooling: What package manager is being used for JavaScript? npm? Yarn? Something else even? How are asset files being built? Webpack? Parcel? Vite? Other? What else does the build and/or QA tool chain include?
• Dependencies: When will you remove the last Git sumodules? Are there embedded third-party dependencies? What is pulled in via Composer? Where do third-party (MU) plugins live? Where do company-internal dependencies live?
• Scripts: Does the project use NPM scripts? Composer scripts? How complex are they? Are there other scripts? Bash? Node? PHP? Where are they? How easy is it to understand the whole CLI setup? Does the project use a task runner, still?
• Config files: To what degree are config files customized? Which ones are using a common base file? Where do they live? Project root? .config folder? Tool-specific folder? Are they named custom? Or tool defaults? Distributable (i.e., *.dist) files?
• Branches: What’s the default branch? master? main? Something else? Is there any kind of branch protection set up? What environment does the default branch represent? Dev? Staging? Production? None of that? Is there a dedicated release branch?
• Deployment: What’s the process? Who does it? When? Scheduled or ad hoc? Tags? Releases? Changelog?
• Templates: Are there templates for new tickets? PR templates? How are they structured? How much boilerplate is there? How much is missing?
• Documentation: Is there any kind of technical or end user documentation? Where is it? Tickets? Wiki? Drive? Confluence? Who owns updating/maintaining existing documentation? Are technical decisions documented?
• Glossary: Is there a glossary of terms? Is it for internal use only, or shared with stakeholders? Where does it live? Who owns and maintains it? When? How?
• Manual testing: How is manual testing done? By whom? When? Is this documented? Is this tracked?
• Coding standards: What coding standards (and versions) are being used? When and where are they used? Manual? CI? Pre-commit? Pre-push?
• CI: What CI service(s) is or are being used? What are they doing? When are they doing it? Push vs. PR?
• Access: Are there any tools, services or anything that requires access? How easy and quick can this be provided?

Now you go…