Corran wrote:Nya-chan Production wrote:We are now working on the core, not features, so it's pointless to ask about those now.
I disagree. If you know the overall vision of what you are eventually going for you can make important yet seemingly simple design decisions early in the core development to accommodate the development of additional features down the road. If you don't plan ahead you may be pulling your hair out and refactoring a lot of code later on.
You two are actually in agreement, save the matter of where the goal is.
Recently Nya and I talked (well, it was more like me ranting) about .org rewrite paralysis. I suggested eliminating
everything that was peripheral to the core of the site -- whatever that core is. I further suggested that it would be beneficial to
think that nothing else existed aside from that core: that core
is what you are eventually going for.
This has the great effect of reducing a large problem to a much smaller one. (I use "reducing" not in the algorithm-analysis sense, since the problems are not equivalent, but in the sense of actually making the problem smaller.)
If that small bit isn't enough? No problem. Deliver a product and do a second iteration of development.
My suggestion for that is to:
(1) identify who your users are (not as easy as it sounds),
(2) figure out what they really want (again, not as easy as it sounds),
(3) break "what they really want" down into features (preferably implemented using an executable testing tool, i.e.
Cucumber),
(4) work on one feature at a time,
(5) do only what you need to do to get the feature to pass,
(6) release each feature as it is completed.
If step (5) results in something that feels broken or half-baked, then there's a few possibilities:
(1) It actually isn't.
(2) The scenarios for your feature don't cover everything that your users want to do. This means that your requirements are incomplete and that you need to run through steps 1-5 again.
(3) You're hitting a code pain point: some bit of code was implemented in a way such that it was solid and worked in a previous iteration, but doesn't do so well now.
This is fine: the cost of refactoring small systems with well-defined outputs (which is a huge benefit of having executable test cases) is really not that high. Refactor or redesign the offending subsystem to fit your new requirements and have another go at it.