> Some features are just fundamentally complicated, [..]
> Fortunately, that doesn't happen very often for most types
> of development work!
Every problem should in theory have some of breaking it down, otherwise we have no hope in programming it. We should be able to break it down far enough that it can be reasonably sanity checked. If the feature is too complicated then you're asking for bugs.
From an objective/goal stand point, we also need some way to measure our progress and be able to evaluate whether a pivot is required. It's very easy to get stuck in a problem for a long time if we have no external measure.
Every problem should in theory have some of breaking it down
I don't see why we should expect that to be the case. For example, I once had to implement an algorithm to visualise a certain set of data using a certain type of diagram, where there were a lot of technical factors that determined exactly how that diagram should be drawn. IIRC, it took a few weeks to implement that algorithm, but there weren't any natural breaks where you could, say, draw only half of the data set or half of the diagram features and get a meaningful result. It was inherently a relatively complicated, all-or-nothing feature.
It's hard to argue a feature I haven't seen, but just the fact you are able to program the feature means you were somehow able to break it up into a series of steps. Okay, breaking it down wouldn't produce something workable in itself, but it should produce something measurable, testable even.
For example:
Step 1 : Extract relevant data
Step 2 : Massage data into the correct format for graphing
Step 3 : Graphing tool visualization for simple example data set
Yes, it was implemented in a series of steps, but the cumulative result of those steps had zero business value and was not something that would ever have been released to customers until the final step was done.
> Fortunately, that doesn't happen very often for most types
> of development work!
Every problem should in theory have some of breaking it down, otherwise we have no hope in programming it. We should be able to break it down far enough that it can be reasonably sanity checked. If the feature is too complicated then you're asking for bugs.
From an objective/goal stand point, we also need some way to measure our progress and be able to evaluate whether a pivot is required. It's very easy to get stuck in a problem for a long time if we have no external measure.