Trade-offs with Early Development

Every time I start a new project, I have some decisions to make, outside of the tech stack.
  • Do I write tests
  • Do I use props
  • Do I use TypeScript
  • Do I use a Linter
  • Do I use a formatter
  • Do i use Documentation Comments
It may seem like bad behavior to have this conversation. After all, are we not suppose to have 100% test coverage, well documented code, and all the safe guards in place to prevent bugs and errors in the future? Am I just trying to get out of work? Yep! Here is why...
Every project has different scale, timeline and risk. The more complex the project, and the more people you work with, the more you need these tools. Let’s start with the basics.

Linting and Formatters

These are probably the least controversial of the bunch. And it does not take a lot to see the value. For formatting I have started to use the default prettier setup. I use to care about the choices and the decisions. Now? I just role with the punches and allow the defaults to make the decisions. I don’t even try to have it audit, I just allow it to format on 1st Save` and `Paste`. My mental energy is not longer spent caring about double vs single quotes, or trailing commas.
Linting is a little harder. While it is easy to setup, I don’t care for the the VS Code integration. I find it distracting. As a secondary process, I largely ignore it. And I don’t feel the value when I am the only developer. That being said, the second the number of developers grow, the more impactful this becomes.

Props

Using React, and React Props is something I use to believe in. It seemed like the “correct” thing to do. Now? I think they are largely a giant waste of time. The most important thing about props is to allow the documentation of the interface for a component. They themselves don’t offer great documentation outside of a API. JS Doc does a much better job of making it clear the intent and the interfaces.
I find the overhead of writing them not great. And TypeScript and JS Doc can replace them with better tools. So React Props are a no go for me. Additionally, I find that the interfaces are constantly changing, and these are a lot harder to maintain.

TypeScript

I love typescript. I have been following the project since it was announced and everyone was against it. I think it is great that it is a superset. It is well thought out. But it is not without overhead and issues. The typescript compiler can be fairly slow. Once, I thought this was valuable even for single developer projects. Now? I am not sure.
After using Deno, where TypeScript is a first class citizen, I feel it only makes sense when I don’t have to face the impact. I wrote a whole compiler and bundle with it using Deno. It really is great. Having a older Next.js project with TypeScript, and seeing the longer compile times, makes me realize that it is a trade off that may not be worth it with Node and Webpack.
I do feel as the team grows, it’s more important. But it is a lot of lines of overhead for small teams.

Testing

I hate tests. I mean writing them can be fun sometimes. But seriously, I almost never find front-end tests to catch anything useful. For APIs and backend logic, absolutely. But unit tests and jest snapshots have largely been a waste of resources on the front-end.
I am starting to think that we should focus on critical path tests using Cypress. And write unit tests when we have bugs and failures so we ensure we don’t repeat a mistake. The idea is to minimize the churn of writing tests to just the parts of the app that see the most impact. And ensure we don’t duplicate issues.

Final Thoughts

I would rather be able to move fast and react to issues, and have the ability to recover fast, than front-load so much work. I can always add these items later as needed. But I can’t move as fast upfront, if I spend all that time working on tooling.
This is why in all projects I have done recently, I focus on recovery and rollback. I focus on feature flags. I focus on small incremental builds. Large releases are bad most of the time. Large code bases are hard to maintain. Let’s start small, deploy often, and recover gracefully.