The second chart -- where it's referred to negatively as a "cliff" -- is the only kind of workflow that I think is healthy (at least for the kinds of problems that I've tended to work on). I rarely work longer hours in that set-up, and all those early parts of the curve where it looks like things aren't being completed -- that part is usually where I am the most productive.

I spend the first while reading, researching, drawing pictures, and just generally thinking about the problem. The idea of even caring at all about closing a ticket or issue at the early stage doesn't cross my mind. It's too soon. Zero tickets should be closing. You haven't thought hard enough yet. This applies equally well in a two-week time frame as in a multi-month pilot or prototype research phase.

Later on, I am reaping the rewards of the compounded growth of the thinking and ruminating that I did. I can close issues way faster than normal (without working longer hours, without exhausting myself, and without introducing dangerous bugs). This is because I took the time to actually think about what I was doing. I didn't let the false productivity of merely closing tickets or issues (i.e. stupid bullshit overhead that I enter into a stupid bullshit tracking system) get in the way of actually doing my job (which is to think first and act on that thinking later).

The fact that these graphs tend to converge, naturally, to the "cliff" scenario should be a big signal to people that that's what humans do. That's how they work. Humans produce solutions to hard knowledge problems in a way that is like a Poisson process. After "integrating" on the problem for a while, a solution "discharges" like a lightning strike, based on the compounded growth of your investment into actually thinking, instead of prematurely trying to do something just for appearances sake.

This is relatively more true for "research" problems, where you can have a chance encounter with something that suddenly makes the problem way harder than anyone thought, as opposed to what some people seem to think are "mere implementation" problems, but the effect still happens in both cases. And even more, "mere implementation" problems usually aren't. Usually those too involve research time regarding refactoring and design ramifications of the implementation.

This is among the fundamental reasons why I disagree with the premise of modern Agile-like techniques. They take a view that fundamentally, all of the tasks within a given cycle are roughly fungible and commodity work. Management seems to think that it's somehow a managerial task to "drive" workers into situations where they produce linear-like burndown. Instead of stopping and saying, wait, we should be figuring out how people work and then setting up the stream of business needs so that it gets satisfied by the way people work. Not saying that you have some preconceived idea of how the business needs have to be satisfied (usually because it would be politically convenient for you if it could be true), and then seeking to implement that regardless of what human beings do when they work.

Anyway, in a sense it depresses me that this kind of burndown bullshit has been so erroneously legitimized by middle management in bureaucratic organizations that we now actually have to spend even more brain cycles debating exactly what shape the burndown graph should have. Total bikeshedding loss for us all. Why not just not have burndown and stop pretending like keeping one's finger on the pulse of ticket-closure-velocity has any relationship to the real world aside from whatever one can politically sell to one's boss?