Hacker News Reader

The distinction is only artificial because we are in early stages of development. Our MVP will require a web client and an intermittently offline mobile client.

It is helpful, but certainly doesn't sound simple. Feature switches would require the messages to already be designed, which is most of the work already done. It also sounds like an edge-case nightmare.

View on HN

Add new features in the backend first...then the clients can add the new features over time. The feature toggle is that the web client just hasn't added the feature yet!

I usually put integration tests in the client repo but it doesn't matter. The key is that you put in a trigger so they get run by changes to any of the projects.

For me, feature switches make things easier because they decouple pushing out code from making a feature live. If you're working on a new feature, you put it behind a switch that both client and server check. If the client is ahead of the server (or vice versa) it doesn't matter.

You don't want a lot of half-baked stuff hanging around, so you should definitely limit WIP and be aggressive about removing switches once you're sure you won't be switching something off. Without that, it could indeed be nightmareish. But branching can also get nightmareish. Either way, the trick is to minimize complexity.

Reply on news.ycombinator.com