The glorification of technical debt.
A 'good problem to have' is 'we need to scale to handle another 1 million users', not missing basic functionality.
If it's a nice problem to have, don't solve it now
11–20 of 71 posts
Re: If it's a nice problem to have, don't solve it now
#12I take a different attitude to "nice to have" problems. I work on a professional services team that is massively undersized relative to demand. Our role is less than a year old within the organization. We have far more clients in need of support from my team than we can give. This is a great problem to have - lots of pent up demand. Nevertheless, it is a problem, and we must actively strive to solve it. It's nice to…
>Ninja edit: this is in contrast to things that aren't a problem yet. E.g., in the article, the author discusses not having password reset functionality. That is not yet a problem in the absence of users. It's not a nice problem to have. It is not a problem.
That's the crux of it. The headline is catchy, but the author isn't talking about nice-to-have problems. He's talking about recognizing if something is a problem right now, or only a problem at some point in the future.
IMO, the article is click-bait.
Re: If it's a nice problem to have, don't solve it now
#13I take a different attitude to "nice to have" problems. I work on a professional services team that is massively undersized relative to demand. Our role is less than a year old within the organization. We have far more clients in need of support from my team than we can give. This is a great problem to have - lots of pent up demand. Nevertheless, it is a problem, and we must actively strive to solve it. It's nice to…
> It's not a nice problem to have. It is not a problem.
I think you misunderstand his word usage, though you're seemingly following the same process.
A "nice problem to have" is one that results from having success. Yes, he doesn't have the problem now, because he's got no users, so indeed, having to reset the passwords of existing users would be a "nice to have" problem.
You're already in the "nice to have" zone (clients with problems to solve!), and you want to fix those problems brought on by popularity.
Re: If it's a nice problem to have, don't solve it now
#14I take a different attitude to "nice to have" problems. I work on a professional services team that is massively undersized relative to demand. Our role is less than a year old within the organization. We have far more clients in need of support from my team than we can give. This is a great problem to have - lots of pent up demand. Nevertheless, it is a problem, and we must actively strive to solve it. It's nice to…
>Ninja edit: this is in contrast to things that aren't a problem yet. E.g., in the article, the author discusses not having password reset functionality. That is not yet a problem in the absence of users. It's not a nice problem to have. It is not a problem. That's the crux of it. The headline is catchy, but the author isn't talking about nice-to-have problems. He's talking about recognizing if something is a problem…
Short, information dense, titles are hard :-)
The full question I ask is "From my perspective right now, is this a nice problem to have?" - emphasis on the first part.
I certainly didn't mean for this to be click bait, just wanted to share something that's been valuable for me with others in the hope it might be useful. I might work on the title.
Re: If it's a nice problem to have, don't solve it now
#15The 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 the larger picture instead of just rushing to just rely on an email and password column in your MVP. That way when you demo your app to an investor or early beta users, you won't be stuck saying "oh, there's no password reset, just create another one".
Re: If it's a nice problem to have, don't solve it now
#16I take a different attitude to "nice to have" problems. I work on a professional services team that is massively undersized relative to demand. Our role is less than a year old within the organization. We have far more clients in need of support from my team than we can give. This is a great problem to have - lots of pent up demand. Nevertheless, it is a problem, and we must actively strive to solve it. It's nice to…
> It's not a nice problem to have. It is not a problem. I think you misunderstand his word usage, though you're seemingly following the same process. A "nice problem to have" is one that results from having success. Yes, he doesn't have the problem now, because he's got no users, so indeed, having to reset the passwords of existing users would be a "nice to have" problem. You're already in the "nice to have" zone (cl…
Yes, spot on, this was what I wanted to get across. Thanks.
I fully agree with everything GP said, by their understanding of what I meant. But yeah, to be useful the question has to be forward looking. Would things have to change for the better for this problem to actually manifest.
Re: If it's a nice problem to have, don't solve it now
#17The 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 bucket are natural to postpone. Finding the balance between the first two is one of the primary challenges of engineering.
Re: If it's a nice problem to have, don't solve it now
#18The 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?
Re: If it's a nice problem to have, don't solve it now
#19The 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…
Definitely.
People who think their problems are small or simple write their own libraries, and then every change in requirements gets incorporated into the library or blamed on the victim. By the time the system is profitable you've reimplemented half of a robust library, badly.
Re: If it's a nice problem to have, don't solve it now
#20As 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 features you don't consider necessary, do things in ways that make them difficult to return to later and throw it in the "technical debt" pile.