Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If it's a nice problem to have, don't solve it now

davidnicholaswilliams.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: If it's a nice problem to have, don't solve it now

#61

Post by fragmede »

rmoriz wrote: post #49
freewilly1040 wrote: post #44

Earlier quoted context omitted.

A decent eng will know that there are managed solutions for this problem that you don't have to build yourself. In 2020, with the number of managed solutions out there for simple CRUD functionality, the default should be just using the managed thing until it doesn't suit you, not just ignoring critical yet non-unique pieces of infrastructure all together.

Not necessarily. If you have 0 customers but your MVP already depends on a bunch of external services, you have hard lock-ins or running costs from the beginning. Scaling and putting everything on scalable infra should be reserved for projects that make it past a couple of paying customers (= validation).

Don't be penny-wise and pound foolish though. Let's pretend I take a month to design, pick, configure, operationalize, and integrate with the project, a pub/sub bus that will cost $0 while it's not running by developing it as VMs on hardware I own. A hypothetical alternative costs $x/month for the first Y billion messages. If I'll never exceed 1,000 messages/month, having a hard rule to avoid running costs would argue for taking a month to build such a system.

A more pragmatic approach involves examining X and Y before deciding not to pay any money. (They're also different for everybody, and it also depends on your financial situation.) If X is less than the cost of 1 coffee from a local coffee shop, I personally would pay for it rather than spend the month building my own $0 monthly unused cost pubsub bus for 1 month.

(Time it takes to implement is a 3rd variable, Z, though I'll note that estimating software project is notoriously difficult to get right.)

Re: If it's a nice problem to have, don't solve it now

#62

Post by frandroid »

dakiol wrote: post #18
frandroid wrote: post #15

The problem with issues like this is that this is patch development. If you don't look a couple steps ahead and at least think through your "nice to have" problems, you might end up getting the architecture wrong. The password reset problem might drive you to find an authentication library instead of rolling your own. Suddenly, your "nice to have" problem is fixed before you get to it, because you decided to look at…

I'm curious, what's the right alternative to having an email and password columns in a "customers" table?

Cognito is a popular auth service that's used by many people who want to launch an MVP on AWS, for example. You would not keep the password yourself at that point.

Later on you might realize that you've bound your user ID to email and that you need to use UUID, where email is just a contact address.

You might even want to have users have multiple accounts that use the same email address.

You might decide to bind the user's account to their phone number instead.

It's not about One True Strategy, but about looking further into what you will need in the future. You might decide not to develop something right away, but you can avoid much refactoring later by making a smart decision now that did not involve any more work than the less smart decision.

Re: If it's a nice problem to have, don't solve it now

#63

Post by davnicwil »

ggggtez wrote: post #57
davnicwil wrote: post #43

Earlier quoted context omitted.

The password thing was just an illustrative example, it's not perfect, but the point isn't that you don't need it or that not having it won't be really bad when you have users, it's that whilst you don't have users perhaps there are other things that are higher priority to build first. When those are done, reset password might literally be the next item on your list. You might end up building and shipping it before a…

And data security will come exactly: never. Because security is never the most important thing. A company that runs with this mentality will always be reactive, and never prepared for threats.

Security is foundational. It's not something to add later. Without it, signup is not done and shouldn't be shipped. Ironically, not having the reset password functionality actually reduces security bug surface area :-)

Re: If it's a nice problem to have, don't solve it now

#64

Post by pandamaniac »

Does anyone else feel like we are all trying to be high growth startups?

I understand that we all want to build products which others use and pay for but why not also be building things for yourself?

Is it really such a bad thing to spend some time over-optimizing pieces of a system for your own pleasure and possibly learning things along the way?

Re: If it's a nice problem to have, don't solve it now

#65

Post by paul_f »

quanticle wrote: post #42

Whilst I'm building signup, I realise that I probably also need reset password functionality. If a user signs up, but then forgets their password, that's a problem. But from my perspective right now, is this a nice problem to have? Actually, yes! I have zero users, but having this problem implies I would have users, which would be great. Reset password functionality is important, and will absolutely be required event…

One must always consider opportunity cost. Adding password reset functionality might take time away from building features that solve true end user problems. People will wait for a password reset, they won't wait if you cannot deliver true value to them.

Re: If it's a nice problem to have, don't solve it now

#66

Post by afarrell »

munificent wrote: post #17
frandroid wrote: post #15

The problem with issues like this is that this is patch development. If you don't look a couple steps ahead and at least think through your "nice to have" problems, you might end up getting the architecture wrong. The password reset problem might drive you to find an authentication library instead of rolling your own. Suddenly, your "nice to have" problem is fixed before you get to it, because you decided to look at…

This is a great point. It's important to be mindful of the path dependence you are creating for your future self. At any point in time, I think you can roughly bucket problems into three categories: 1. This is a blocking issue now. 2. This is not a block issue now, but postponing will cause more pain than we would save by not doing it now. 3. This is not a blocking issue and doesn't create future pain. The third buck…

I think there is a 4th category: This is not an obviously blocking issue right now, but it creates enough mental load that it prevents my work from being rewarding.

Re: If it's a nice problem to have, don't solve it now

#67

Post by afarrell »

ysavir wrote: post #36
superfamicom wrote: post #20

As a person who has worked at many startup, I get it, "shipping" features is important. As an engineer working at many startups, this is a sad and painful reality of working under product driven ideas and "first to market" type things- basically anything that doesn't (usually) involve life or death, or federal regulation is rushed out the door when it can be. As a user, I absolutely 100% hate this mentality. You skip…

I think the "ship asap" is necessary for brand new startups. If you can't generate the user growth necessary to secure the next round of funding you'll be out of business, and that time spent writing the ideal code was not only a waste of time, but also a potential cause to the slow user growth. In its first year or so, until it receives enough funding to stabilize, it makes sense for a startup to give more weight to…

> ideal code

One problem in these discussions is that people quickly start using absolutist language, which makes it hard to find balance.

Re: If it's a nice problem to have, don't solve it now

#68

Post by afarrell »

davnicwil wrote: post #63
ggggtez wrote: post #57

Earlier quoted context omitted.

And data security will come exactly: never. Because security is never the most important thing. A company that runs with this mentality will always be reactive, and never prepared for threats.

Security is foundational. It's not something to add later. Without it, signup is not done and shouldn't be shipped. Ironically, not having the reset password functionality actually reduces security bug surface area :-)

Which is an argument in favor of leaving off some features. Don't half-ass password reset. Wait until you have the need to whole-ass it and make things conceptually-coherent.

Re: If it's a nice problem to have, don't solve it now

#69

Post by peter_d_sherman »

>"It's good advice, but hard to follow in practice. Often when you explore solutions to a problem, even simple ones, the problem reveals itself to be more complex than you'd anticipated. You find sub-problems, and tangental problems, which look just as important as the original. It's easy to go off track and end up deep into the problem you were supposed to just find a quick solution to. After all, it's just one more thing, you're thinking about it, and you'll have to solve it at some point anyway. Why not now?

I've made this mistake a lot. I'm trying to get better at being strict about saying "not now" to new problems that I discover in the middle of an iteration, and avoid getting sidetracked from shipping by working on things that can be left for later. I'd like to share a tactic I use to do this that has worked well for me. It's to ask a simple question about each new problem I encounter: "From my perspective right now, is this a nice problem to have?". If yes, I skip it. If no, I work on it immediately."

Opinion: There is great value to persisting problems that can be instantaneously or quickly solved, if only for the simple reason that they can be thought about; meditated upon; and other/better/more novel/more creative/more elegant solutions devised -- than the one initially determined by one's mind...

In fact, if in the future, I built a large company, and solved all known business problems (well, in that business's industry!), then I'd probably want to get rid of that company and start over again with nothing!

Why?

Well to again rethink/reengineer better solutions -- to the problem set that I once faced as barriers!

You will always think more creatively the second (and nth) times you revisit problems and problem sets!

This might sound crazy to most normal people -- but I value problem solving skills over money.

With problem solving skills, you can always get money -- but the reverse is not always true...

Anyway, excellent article!

Re: If it's a nice problem to have, don't solve it now

#70

Post by ysavir »

afarrell wrote: post #67
ysavir wrote: post #36

Earlier quoted context omitted.

I think the "ship asap" is necessary for brand new startups. If you can't generate the user growth necessary to secure the next round of funding you'll be out of business, and that time spent writing the ideal code was not only a waste of time, but also a potential cause to the slow user growth. In its first year or so, until it receives enough funding to stabilize, it makes sense for a startup to give more weight to…

> ideal code One problem in these discussions is that people quickly start using absolutist language, which makes it hard to find balance .

Balance also is not quite the correct thing to strive for.

The proper course of action is to work with the leadership to figure out when the expected critical points are for the business. This includes fund raising, IPOs, acquisition, or any other time when the company receives a valuation. The goal, for both the business and the dev team, is to make sure that the company has the best possible value at those exact points. You don't want to peek too early or peek too late. The proper course of action then is to prioritize things in accordance with how they impact those points in time. If one's coming up soon, prioritize the short term almost exclusively. If it's years out, plan ahead as a marathon, not a sprint.

Post reply on HN