4 ms·
There is a balancing point between under-analysis and over-analysis. It's hard to know the true requirements until the system is actually in production. You can
by tabtab 6y ago
There is a balancing point between under-analysis and over-analysis. It's hard to know the true requirements until the system is actually in production. You can't realistically pre-learn many domain lessons: you just have to dive in and see what floats by setting sail.
Finding the best balancing point is hard to turn into a sure-fire formula. I use experience (age) to make a best guess based on on past successes and failures and project types.
One tip is to collect and keep a list of questions and suggestions, and make sure they are sufficiently explored. You can't answer questions that have not been asked, but AT LEAST answer those that are asked. Make sure staff is not afraid to ask questions or make suggestions.
- flavius29663 6y agoYou have to release the software, with hardcoded inputs, limitations and bugs. That is fine. Having a clean code helps you then quickly polishing it and evolving it based on the customer needs. I prefer that to an over designed system, that is 80% clean and 20% crap, because that is hard to change as time goes by, and that 80% will stay the same, but will become 50% and then 10% of the total codebase.
- tabtab 6y agoNobody agrees on what "clean code" is. I agree there are rules of thumb most will accept, such as try to be modular (group related things together), manage constants in a table or central class instead of hard-wire them, factor heavily repeated patterns into subroutines/methods/classes, comment at least the "big picture" of sections, and the oddities.