Ask HN: How do you develop large complex software
1 comments
Your only operative complaint is "confused." What are you confused about? The high-level goals and requirements? Your own approach and criteria for success? Structuring your time/effort?
Without knowing what you are asking exactly, there are a ton of ways to structure a large project.
One of my favorites is: Pick some challenging (but not too challenging) use-case that intersects an interesting subset of the core requirements. Decide on ONE design principle you want to follow (highly testable, clear separation of concerns, pluggable sources/endpoints, whatever) and then build the crappiest/minimal version that does those two things (handles the main use-case and strictly adheres to your design principle) while being totally crappy in every other way (i.e. bad UI, brute-force algorithms, whatever). As you design/build this "slice"/MVP of functionality, keep notes about out-of-scope parts you can't/won't touch according to the rules above. Those will become seeds for the rest later.
This method yields a lot of advantages: 1) It provides a way to get started without analysis-paralysis, 2) it results in proof-of-concept, perhaps a demo for what you are going to eventually build, 2) You think through a lot but don't build so much or get lost in details you won't build, 3) If you hate the MVP, you can throw it away and build it again the right way (which will be better, as a result).
For a really big project, just iterate on the above by picking more slices/use-cases. You might have to refactor/redesign as you go but pretty quickly you'll have built up enough scaffolding that the rest of the project will flow easily or be delegated easily.
Without knowing what you are asking exactly, there are a ton of ways to structure a large project.
One of my favorites is: Pick some challenging (but not too challenging) use-case that intersects an interesting subset of the core requirements. Decide on ONE design principle you want to follow (highly testable, clear separation of concerns, pluggable sources/endpoints, whatever) and then build the crappiest/minimal version that does those two things (handles the main use-case and strictly adheres to your design principle) while being totally crappy in every other way (i.e. bad UI, brute-force algorithms, whatever). As you design/build this "slice"/MVP of functionality, keep notes about out-of-scope parts you can't/won't touch according to the rules above. Those will become seeds for the rest later.
This method yields a lot of advantages: 1) It provides a way to get started without analysis-paralysis, 2) it results in proof-of-concept, perhaps a demo for what you are going to eventually build, 2) You think through a lot but don't build so much or get lost in details you won't build, 3) If you hate the MVP, you can throw it away and build it again the right way (which will be better, as a result).
For a really big project, just iterate on the above by picking more slices/use-cases. You might have to refactor/redesign as you go but pretty quickly you'll have built up enough scaffolding that the rest of the project will flow easily or be delegated easily.
I am for the first time the main developer on a large project at work, I don't feel like what they are asking is unreasonable. I’m saying that in case people believe that they are setting me up for failure.
I'm managing adjustments to a large database and a large codebase of 2 APIs, and a WebApp. I find myself confused and spend more time cleaning my code then actually developing.
.NET and blazor if that matters
Any Tips?