3 constraints before I build anything

21 points by schmudde

spc476

This advice seems to only apply to the HN-entreprenure crowd. For my own projects, I don't need a one-page overview; usually a once-sentence overview is enough. And for Enterprise Agile, I'm told what to build (or extend) as someone else way above my pay grade had the idea.

I'm also unsure about the "core technology" bit. git wasn't designed as it was more of a reaction to Linux being banned from using BitKeeper. git isn't a "core technology" of Linux. Useful, yes. Core? Not really---Linux went for about a decade without version control (officially, before BitKeeper). Google doesn't use Kubernetes, and I have my own cynical reasons as to why Google released it, and it's not because it's a "core technology" to Google. And this is the first time I've heard of HCL.

gnyeki

The way I understood the core technology bit, sticking with Git as the example, is plumbing vs. porcelain. (Or somewhat similarly, libgit vs. the CLI.) Git wasn’t built with only the porcelain in mind, the plumbing was there too, which made it easier to reuse the “core technology.”
- Johz
  
  I don't think it's that, I think it's more related to the whole innovation tokens concept, where you've got to pick boring tools to build on in most places, but you can choose (say) three interesting technologies that are more experimental. Except this is flipping it around to say that you must choose one technology that is completely custom built and new. And I think the justification is that if your project doesn't work out, you can instead pivot to selling this technology directly.
  
  So with Linux, the goal is to create a cool new operating system, but at the same time, Linus created a completely new VCS as his brand new technology. Or Google created a search engine, but they also built k8s to manage their server infrastructure.
  
  It is an odd argument, I don't find it compelling at all.
mcherm

I think this advice would have been more useful to me if accompanied by some examples. I understand the idea of a "one page" description of your project. But "core tech separable from the product" is not something I really understand, and "one defining constraint" would be a lot more helpful if I had examples of some existing systems and what their "one defining constraint" was (besides Minecraft and IKEA).
veqq
I wrote this in my notes:

3 constraints before i build anything suggests:
- write 1 page describing all ideas to organize thoughts, help communicate etc. If you can't fill the page, you don't have enough detail to build. If it needs more pages, it's too complex
  - Example: https://jordanlord.co.uk/blog/growth-engineering/
- separate out the core tech from the product (e.g. method/skill/tool) which can be reused fr other things (e.g. extractaing a library out of the code base). this core tech is the long term commitment. If the idea doesn't enable core tech, it's not high enough leverage
- focus the product around a constraint which gives it identity. IKEA is flatpack self assembly. This constraint limits scope/decision space.
Relatedly, the "Lenin Document" idea about placing random extra ideas and features into a description of the maximalist vision to keep them away from your core planning, but still document them. Further:
- product must fufill an acuate need (and not just a theoretical one). It's important to feel the need yourself too.
- then form idea to met the need (must work from need to idea, not start with an idea and look for needs it could serve)
- write hypothoses which should be true for the idea to succeed
- pick the most important hypotheses and try to prove them true (no reason to build on a shaky foundation... make it strong first). What's the minimum necessary to test it? (Originally called MVP, which got hijacked...) (The linked article details testing, metrics etc. The article has a lot of detail about random parts irrelevant here)