If it's a nice problem to have, don't solve it now • Hacker News Board

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

#51

Post by MaysonL » Mon, Aug 10, 2020, 11:01 PM UTC

solatic wrote: post #45

rigel_kentaurus wrote: post #30

This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…

> That is why a very technically solid person is gold in the first round, because they can design the signup in such a way that it's prepared for future requirements. They of course would also know that you can't store in plain text, that it should be hashed, that you might have to use a vault, that you need to randomize the hash, and that in the future limit access to the "user" table and never ever expose it throug…

Assuming that Google or Facebook or Github has implemented a library correctly, and that it will remain available as long as you want your app to function is dangerous.

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

#52

Post by stickfigure » Mon, Aug 10, 2020, 11:41 PM UTC

freewilly1040 wrote: post #44

rigel_kentaurus wrote: post #30

This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…

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.

Reality is nowhere near this rosy. Sure, maybe you can get away with canned auth, but I took that as illustrative.

A more practical example: Start/stop/change subscription plans. Until 12 days ago, Stripe had no customer portal so you had to implement this yourself. You can do it with support email, and "easy to switch plans" is not on any prospective customer's checklist.

"Too many change plan emails" is a good problem to have - deprioritize the feature. And if you're lucky, by the time you really need it, your billing service will have implemented the feature for you.

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

#53

Post by Dudenoso » Mon, Aug 10, 2020, 11:43 PM UTC

MaysonL wrote: post #51

solatic wrote: post #45

Earlier quoted context omitted.

> That is why a very technically solid person is gold in the first round, because they can design the signup in such a way that it's prepared for future requirements. They of course would also know that you can't store in plain text, that it should be hashed, that you might have to use a vault, that you need to randomize the hash, and that in the future limit access to the "user" table and never ever expose it throug…

Assuming that Google or Facebook or Github has implemented a library correctly, and that it will remain available as long as you want your app to function is dangerous.

As opposed to assuming that you'll implement it correctly when Google or Facebook or github haven't?

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

#54

Post by chiefalchemist » Tue, Aug 11, 2020, 12:36 AM UTC

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…

Yes. But if you're not meeting user expectations they're not going to tell anyone, and so and so on. The satisfaction of current users has to factor in some where. Else no word of mouth, and expensive churn.

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

#55

Post by hrishios » Tue, Aug 11, 2020, 2:15 AM UTC

crdrost wrote: post #37

rigel_kentaurus wrote: post #30

This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…

Yes! Scaling problems are extremely nice to have. May you be so blessed that all of your problems are scaling problems! People spend so much time trying to preemptively solve scaling problems and proactively design around scale. I am being 100% serious when I say that this is an absolute total mistake. Scaling problems are just the absolute best to have, you shouldn't run away screaming from them before they happen.…

Agreed about scaling problems, but the examples you provided illustrate that, in my experience, there are still things you should be doing from the get-go.

Building things that don't scale is often taken to the extreme where it's nothing more than a few HTML pages strung together by self-rolled crypto and javascript. This might be good for idea validation (first couple of days), but it shouldn't persist past this point.

Understanding when the inevitable problems pop up and being able to solve them in reasonable enough time not to lose your users is - to me - not a nice to have problem. It's a showstopper that will turn egg on your face problems into fatalities.

Few things I would recommend are:

* Instrumentation - You don't need to go full ELK before you find product-market fit. Hell you can log everything, and with two users you can always read all the logs. But something is key. * Up and down scripts - How long will it take you to set up a new copy of the product? Do you have to trawl bash logs and have a team meeting to find out all the configs that need to be set up? * Load-testing - Again, nothing fancy. Just put curl on a bash loop and see where the system starts to hiccup. Once you have real users with complex data on real hardware you'll wish you profiled things, even slightly. * Instrumentation - I say it again because the sheer number of systems I've found on the verge of silent failure and user frustration because the errors weren't being propagated, be it from client side to server or from the logs to an alert, is massive. With modern SPAs it's easy to think everything works when all your users see is a blank page. * Please don't roll your own crypto. Unless you're working in a language that is 2 days old you really shouldn't need to or be doing this.

In short, if you're using HPAs and Kubernetes you've gone too far. But don't choose your instance size at random, be able to set up a new instance in an hour, and have at least 60% confidence that if there is an error you will know about it.

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

#56

Post by ggggtez » Tue, Aug 11, 2020, 3:21 AM UTC

danShumway wrote: post #6

Just to push back a tiny bit on this, sometimes nice problems can turn into nasty problems very quickly. "My customer data isn't backed up", is a nice problem to have when you're just launching a new service and don't have any customers. But it's still a problem you'd probably like to solve relatively early. There won't be a moment where missing backups are an immediate problem but also still easily solvable; they're…

No don't you see! If you get sued for misusing your customer's data, that means you have customers! So getting sued is actually a good thing!

Make your money and burn down the building on your way out!

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

#57

Post by ggggtez » Tue, Aug 11, 2020, 3:27 AM UTC

davnicwil wrote: post #43

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…

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.

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

#58

Post by beachy » Tue, Aug 11, 2020, 4:39 AM UTC

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?

One alternative is to use something like Keycloak or some other auth tech.

Then you'll have password recovery, 2FA, sign in with FB/Goog/LinkedIn etc., loads of insightful management screens and even SAML support for enterprise SSO - all free, out of the box, battle-hardened and already in wide use with many eyes on it for security.

Then when your customer waves some IT checklist in front of you asking you "do you support blah blah password complexity" the answer is just YES.

The TFA has a solid point, but has picked a bad example to illustrate it. These days if you find yourself even thinking about building your own password recovery, even way off in the future, you should really reexamine your core decisions.

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

#59

Post by smichel17 » Tue, Aug 11, 2020, 4:46 AM UTC

rigel_kentaurus wrote: post #30

This can also be summarized as "Early on, don't be afraid of doing things that don't scale". In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else. The key…

> In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use.

That's exactly what I just did at the soon-to-launch startup I'm currently working at. There is a change password function, but no password reset (or other systems that would require generating stateful links for emailed). As an added bonus, if you try to sign up with an email address that is already in use, the automated email you receive (from an address monitored by a human) includes something to the effect of "If you aren't sure of your password, reply to this email and we'll get it straightened out."

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

#60

Post by yjftsjthsd-h » Tue, Aug 11, 2020, 5:30 AM UTC

Dudenoso wrote: post #53

MaysonL wrote: post #51

Earlier quoted context omitted.

Assuming that Google or Facebook or Github has implemented a library correctly, and that it will remain available as long as you want your app to function is dangerous.

As opposed to assuming that you'll implement it correctly when Google or Facebook or github haven't?

Yes, because what's good for them is not necessarily what's good for you.