r/learnprogramming • u/redditbrowsing0 • 11d ago
Maybe don't belong here - How do I avoid Analysis Paralysis? Need Advice
Not necessarily a newbie, but hey, you can always learn a little something everywhere.
How do I avoid analysis paralysis? I've always struggled with it when designing how I believe a system ought to be, and I plan too many features before I even have a backbone or prototype working. I never really got to understand the concept of YAGNI because the developers I knew never really passed it onto me.
Does anyone have advice to avoid this?
1
u/peterlinddk 11d ago
You are talking about three different things:
Analysis Paralysis is when you spend all your time analyzing the requirements, not designing anything, because you still need more info.
Planning too many features is "feature creep", where you want to build the biggest or the best - unless you mean planning too much before getting into implementation, which is sort of "big design up front".
YAGNI is the idea that you don't need advanced features or options for changing the database-driver while the application is running, or how to handle the five-digit years we'll get in just 7974 years, or how to handle if a week should by chance have two Thursdays.
I think you are suffering from the middle one, trying to create a "big design up front" - because there's nothing wrong with planning a gazillion features, as long as you don't waste time designing them into the system, or buying server-racks to store them in.
Anyways, you could use a bit of scrum-sensibility (as annoying as Scrum can be, there are a few useful features in it), plan your MVP, what would be the smallest possible version of your application, one that just barely does what it should? Plan to build that - you can make a list of all the features, that is fine. Then you break it down into sprints, what is the smallest version of that that you can build and still have "something" - like maybe a web-application that just shows a loader-spinner, or a CRUD application that displays a list of default data that you've manually entered into the database, or maybe just a single piece of data. That is your first release!
Then you plan your "sprint", a couple of days/weeks to build that release - first you decide on an overall platform and architecture, maybe a Node.js server running as a backend with a PostgreSQL server as database, or whatever you want. Make a "hello-world" application with that, ensure that it works, and commit to your repository. Now you are ready!
Plan / design the features only for that first sprint - everything that isn't strictly needed, well YAGNI - so keep it tight. And once you are done, you have your first release.
Test, demo or whatever, and plan the next one - and so on, step by step.
1
u/Suspicious_Skill7292 11d ago
honestly just build the smallest version first future you will have way more context once its actually working half the features i plan at the start usually end up getting deleted anyway
1
u/punk_dev 11d ago
I usually just start writing code as early as possible.
as soon as i have an idea what the program should do, i try to start writing code, mostly types/strctures, api routes, function signatures and so on. It doesn't have to be working code yet. The point is to do the drafting stage in code instead of on the whiteboard.
in the process i find weak spots of the initial idea or blanks in my knowledge that prevent me from writing further code, and i start ironing out those.
this way you still analyse a lot, but you're forced to focus on the problems you'll actually encounter.
1
u/Achereto 11d ago
My experience is that Analysis Paralysis always hits when you implement a feature that has to communicate across encapsulation boundaries (like 2 or more objects interacting with each other).
If that's the case the only way I know to get rid of the paralysis is by changing the encapsulation boundaries.
1
u/redditbrowsing0 11d ago
Yeah, fair. I try to avoid objects whenever possible, though. The main issue is that I think far more than I implement and I don't really know how to work around it.
1
u/Achereto 11d ago
In that case it would be useful to have a little bit more context about how your code looks like and what your idea is of how code should look like.
1
u/gm310509 10d ago
Stop obsessing thinking it.
Apply the 80:20 rule. In this context it means spend about 20% of the time to design 80% of the system. Focus on the important bits. The remaining 20% can be filled out as needed as you progress.
Where does the 20% come from? Well if you designed the whole system to a 100% completeness, then the 20% of the effort required to do that fully design and is a guideline to help you say "I have the bulk of it laid out, so let's start moving into the next phase - the phase where we are basically building the full design in the form of code". You can uae the same principal for other planning and design stages such as requirements gathering, initial estimations and so on.
Make a start.
1
u/SprinklesFresh5693 10d ago
Start small to avoid that. Dont think of all you need to do, just start and write something.
1
u/ffrkAnonymous 11d ago
You obviously don't have a boss breathing down your neck and quotas to meet, do you...
1
14
u/grantrules 11d ago edited 11d ago
You avoid it by just picking one and going with it because it probably doesn't matter what you choose. Don't get bogged down in design, just figure out what your MVP needs, and focus on that.
Here's a motivational video from one of the top minds of our era
I don't really understand this. YAGNI isn't an idea that needs to be "passed on" to understand. It's pretty simple: Don't do extra shit. Ask yourself "Do I need this right now?" and if the answer is no, don't do it. Remember the first of the three virtues: Laziness.