I prefer to properly scope the time/effort required to complete a feature, rather than having massive features. If a feature is taking more than a few weeks to bring into fruition (assuming ~1 dev per branch), then it's probably too large of a feature and needs to be broken down. A properly sized feature should probably fit within a sprint cycle.
Ideally, I agree, though this does depend on what your business requirements are. Some features are just fundamentally complicated, and it might not be possible to implement the feature itself, or even decompose it into meaningful parts that can be implemented, in one short round of work. Fortunately, that doesn't happen very often for most types of development work!
> 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.
Ideally, I agree, though this does depend on what your business requirements are. Some features are just fundamentally complicated, and it might not be possible to implement the feature itself, or even decompose it into meaningful parts that can be implemented, in one short round of work. Fortunately, that doesn't happen very often for most types of development work!