Eric King

In the U.S., a somewhat recent term was coined to describe the acts that airports go through in order to give the impression that they are increasing travelers' security, but which in fact don't increase security at all, and in some cases may actually worsen it: security theater. This rule about commenting every line of code in order to increase quality smells to me a lot like "quality theater".

They're a real (nasty) monster in one of my favorite video games. pathofexile.gamepedia.com/Plummeting_Ursa

"Given the choice between code that is easy to understand or code that is easy to unit test ..." I hate to choose, so I strive to have both. Not always possible, but more possible than many like to admit.

I find it funny that this question still pops up, year after year, with the same arguments on both sides of the issue. See this SO question as an example. It was eventually closed as 'Not Constructive', basically for thrashing just like this question is doing.

Honestly, I've never seen an example of what you're describing. I don't recall ever seeing a css-layout library advocate using display:table, nor have I ever heard a front-end designer advocate its use over table. It seems hard for me to believe that this is a common occurrence at all. How often would you say you see it?

Bootstrap doesn't advocate replacing table with div for tabular content. They provide styling specifically for tables if that's what you want.

I think this is a fundamentally different question than the one linked above as a possible duplicate. That one asks about semantic markup and div being too generic, this one asks about why we use divs in grid layouts as opposed to the table element.

I think a lot of folks get caught up by the "potentially shippable functionality" wording. It doesn't mean "we better have something that we can deploy to the end users." It means "this is functionality that can be used by our product." The slap-dash we-gotta-get-it-done-in-two-weeks-or-else-so-let's-fake-it code distinctly does not fit the latter meaning.

I'm sure that happens, I've seen it to. But that doesn't mean that's the Scrum way. You said "In SCRUM you sacrifice quality and make the task fit into X days." I was responding to that by saying, no, that's not the Scrum way. The Scrum way is more like "Is there anything we can complete (correctly) and demonstrate by the end of this sprint? If so, that's what we'll do."

So if you can't provide an entire feature in one sprint, you must break down that feature into measurable chunks and provide regular feedback on progress. That's the entire point of sprints.

That goes against the very core nature of scrum (as it relates to Agile)

And what feedback you should provide should be based on useable, real work, not work that is watered-down so it can fit into a sprint

That's the whole point of the sprints... Provide a constant 'heartbeat' of feedback, so nobody's ever more than one sprint's worth of work in the dark

Yeah, it's definitely more professional to deliver the finished chair when it's done. But it's also professional to provide concrete feedback on progress while it's being done.

@Giorgio Sure. A customer will understand "It'll take a month or more to build the whole chair, but in two weeks we'll show you progress towards the first two legs and the back; the rest will come later". What they don't want to hear is "we're not sure how long it's going to take, and we won't have any progress to show you until we're completely done", nor do they want to hear "we couldn't fit the chair you wanted into this arbitrary two-week period, so we built this pseudo-chair for you so we'd have something to show".

@Giorgio Can the chunks be tested? Can they indicate some progress towards a measurable goal? So you won't have a fully functional, customer-usable feature after a single sprint... So what? You've already indicated that is impossible. What's the next best thing? Certainly not 'let's cut corners so we can say we met a deadline (by arbitrarily fitting it into one sprint)'. That's not scrum. Instead, do what chunks you can, and validate that the individual pieces work as designed, even if they aren't incorporated into the whole yet. That's what you present at the end of the sprint.

@Giorgio It is also a basic scrum tenet that tasks take however long they take... You never change a task's duration just to fit into an arbitrary sprint length. Personally, I've never seen a task that absolutely cannot be broken down into smaller, measurable chunks that can fit into a sprint. If the entire task takes more than a single sprint to complete, fine; but are there really no measurable and testable waypoints you can reach along the way? Those are what you complete during the course of a single sprint.

Is this where the party is?

Well, you're doing a good job.

Hi Jin. I like the site design you have going for Programmers