Time, cost, scope. Choose 2.
I came about this concept a while ago, and it stuck, fixed, all over the years.
It's about project management. And it's always a concern when working with software.
It's called Project Management Triangle. Let me tell you more 👇
Constraints of professional software
As you progress in your developer career, you reach a point where "I can't do this" is no more a concern.
It's the same as with any creative discipline after a while 🫡
In other words: anything can be implemented, and you know how to do it, no matter how complex.
After all, most languages are Turing-complete:
A Turing-complete system can, in principle, solve any computational problem given enough time and memory.
More stringent constraints apply at this point: time, scope, and cost.
The catch is that you cannot have all 3 at the same time: low cost, big scope, short time. You must choose two, and sacrifice one:
- Low cost + short time = Small scope
- Low cost + big scope = Long time
- Big scope + short time = High cost
Small scope: Personal project
If you sacrifice scope, you can afford faster times and low budget.
That's how individual creators operate. Small budget and not much time (you are alone after all).
Therefore you must reduce scope 🙌
Startups and bootstrapped businesses are the same. Not much budget, not many resources. That's why you should focus on nailing a specific smaller-scope problem.
When (if) money and people come, you can speed up and increase scope by spending more.
Long time: Vision
If you sacrifice time, you can afford a larger scope while keeping costs low.
You can implement any large system, mostly for free, and alone. But you cannot expect to reach the end in a short time.
Every time I need to work on a task at work, I always ask how much time do I have allocated for it 💁🏼♂️
Anything can be done, if you are willing to spend time for it (and never stop).
High cost: Fast grow
If you sacrifice cost, you can afford to reach big results in a short time.
That's the VC world of startups. You are flooded with money, aimed at hiring people and moving faster.
The size of the project is not much of a concern when you can always put more money to gain time (more people).
Quality
There is another factor in software that it's often neglected: quality.
If a large feature must be shipped fast, the only way is to lower quality.
In practice, ship fast is paramount for most startups. And managers are not qualified at estimating scope (even for developers estimation is a challenge 🫠).
So the natural consequence is lower quality and shortcuts, a (tech) debt that will be paid over the long term.
The inverse is also true: if you keep high standards and high quality, in the long term shipping (larger) feature will tend to get faster 🚀
Slower summer period in tech, with many new releases cooking behind the scenes. Waiting for another surge of innovation coming towards the end of the year.
API design q: if we were to add schema (e.g. Zod) support to the next version of XState, should it be nested under one `schemas` property or separate properties? Or something else? Open to ideas
Specifically, effect v4 and xstate v6 🔜
See you next 👋