found drama

get oblique

Author Archives: !undefined

About !undefined

Syndicated content from the !undefined Tumblr blog where Rob Friesel posts items related to software engineering, user interface/experience design, and Agile software development. Lots of JavaScript here.

re: “Why Scrum Should Basically Just Die In A Fire”

by !undefined

Why Scrum Should Basically Just Die In A Fire:

By Giles Bowkett.

I was resisting the urge to post anything beyond my remarks on Prismatic, but this made enough of the rounds among my circle that I felt compelled to chime in with a couple of follow-up thoughts.

First: we know that Bowkett is smart; we also know that has a tendency toward writing in a deliberately inflammatory or provocative fashion. Given the latter point, I would just chalk this post up to being another “conversation starter” (at best) or else (at worst) the tech-worker equivalent of clickbait.

Unfortunately, what we have here is “Agile” (in general) and Scrum (in particular) playing scapegoat for the bad behavior and cascading ill effects of what is usually just a handful of unfortunately influential but highly poisonous people within a given organization. Scrum, much like democracy, is just a system that can be used, misused, abused, well- or poorly understood, applied genuinely or cynically, etc.

That is a long-winded way of saying that, to the extent that Bowkett is saying that Scrum is flawed… Well, Scrum has problems that make it corruptible. And in that respect, he’s right.

But there’s something that seems a bit self-aggrandizing and disingenuous in his post. The gist: he has an apparently never-ending parade of examples of how Scrum is broken, and how every organization screws it up, and how some poisonous person (usually a manager) is responsible for screwing it up for everyone. But then he has this anecdote about how he got some poisonous CTO fired.

Wow. Now imagine if that situation had played out for all those other poisonous directors, project managers, etc. that he cited. And I pause to ask: why didn’t that happen? Lack of influence? Lack of courage? Inability to recruit allies? Simple lack of effort? It’s a mystery to me because clearly you don’t take on a CTO without those elements at play.

To blame Scrum rings hollow to me. Every one of the scenarios he describes just sounds like someone poisoning the well and the people around him (or her) failing to deal with it for one reason or another.

Which is not to suggest that Scrum is going to save those organizations. Some places are too dysfunctional to survive. But blaming Scrum is like blaming the building or your desk. Move down the block and switch to a standing desk if you want, but you’re still the same people with the same dynamic. Scrum might help your team change its frame of reference; Scrum practices might promote better transparency between you and the rest of your business; but chances are you’re just going to spend the first couple of iteration learning how broken things are and if the business isn’t prepared to deal with that then guess what? Scrum wasn’t going to help you anyway.

His post has plenty of good points. But “Scrum should basically just die in a fire”? Sorry; you’re optimizing the wrong problem.

(And then there’s that wink-wink-nudge-nudge suggestion about how engineers are somehow the superior breed and let’s not go into that tired notion.)

on polyglot programming

by !undefined

Developers are calling it quits on polyglot programming:

Matt Asay, writing for TechRepublic.

Yes, but… (and this is a big but)

I don’t think it’s that developers are “calling it quits on polyglot programming”. I think what we’re seeing (and he touches on this toward the end) is that ultimately developers just want to be productive. Developers will dump Java for something like Groovy because it makes them more productive. (Ditto Scala; ditto Clojure; ditto Ruby; &c.) The Tim Bray quote is a big tell here to that point. It’s exciting to get the opportunity to learn new things; but it’s anxiety-provoking to walk around feeling like you’re expected to have deep knowledge of a hundred unrelated things.

This is what underpins the discussions around “back-end vs. front-end” developer and/or someone who is a “Java developer” vs. a “full-stack developer”. There’s a certain amount of breadth that you need, and ultimately you should stay curious and get out there and learn some new things, but you’ll also suffer if you never settle down for a second and go for depth on a chosen subject.

basically asset-pipeline for SpringMVC

by !undefined

Cool stuff presented by Brian Clozel and Rossen Stoyanchev at SpringOne last week. The tl;dr version would be “Rails-style asset-pipeline stuff for SpringMVC” — but it looks like it goes a bit beyond that. Should provide some nice solutions to static asset and resource management for Spring-based applications, and timely as Spring Boot gains traction.

the illusion of control

by !undefined

“The fundamental problem with viewing JavaScript as the new VM is that it creates the illusion of control. Sure, if we are building an internal Web app, we might be able to dictate the OS/browser combination for all of our users and lock down their machines to prevent them from modifying those settings, but that’s not the reality on the open Web.”

Aaron Gustafson, A Fundamental Disconnect.

This isn’t (just?) FUD around JavaScript and web apps, it’s the reality. And this is the timbre of so many posts over the years: that you have no control over the ultimate runtime of your application’s interface and therefore [fill in the blank].

And so we’re left in this weird never-never land where we can’t really spend all the resources that we need to ensure that we’re reaching (literally) everyone, but neither can we justify rubber-stamping a “best in WebKit (on top of modern hardware)” banner as a way of coming in under-budget. There’s the notion that you can just follow a couple of best practices and be just fine but this doesn’t really acknowledge that not everyone doing front-end development is a Front-End Developer.

To Gustafson’s point about Hanselman’s point about JavaScript deployment basically being a VM… I wouldn’t say that he’s being unfair. After all, Hanselman is a smart guy and I must imagine that he’s making these statements in a sort of Inspired Visionary way. But at the same time… yes, calling the browser a VM is over-selling it a bit. And for all the reasons that Gustafson spells out.

from 10 seconds to 3 seconds

by !undefined

Switching Ghost From Ruby Sass to Libsass:

Paul Davis (Front-End Architect at Ghost) on how they dropped the Ruby dependency from the project and moved Ghost’s SCSS compilation to Libsass.

At the end of the piece I’m still left wondering what (if any) changes they needed to make in the SCSS source itself to support the switch, but seeing the details about how they switched up their compilation was useful.

Anne Lu: Testing with Casper-Phantom-Mocha-Chai

by !undefined

Testing with Casper-Phantom-Mocha-Chai – Anne Writes Code:

A good introductory blog post by Anne Lu about using Mocha (with Chai) in combination with CasperJS. It hits the essential points about using CasperJS, and also shows how simple it is to plug in a third-party test apparatus like Mocha. (Oddly though, her post lacks links to Mocha and Chai and I feel like some readers might get caught off-guard by the “language chains” feature of the casper-chai library.)

the programming equivalent of staring at the abject

by !undefined

“But it has always seemed to me that confronting unfathomable code is the programming equivalent of staring at the abject, of slowing down to peer into the carnage of a car wreck.”

“The Beauty of Code”, an excerpt from Geek Sublime, by Vikram Chandra, as it appears in Paris Review.

Standard Markdown

by !undefined

Standard Markdown:

(Or Common Markdown, whatever.)

Mixed feelings about this.

As I always understood it, “the point” of Markdown was to have a (very) simple “plain text” format that you could scan/read easily without putting it through a parser. Because it was plain text. Right?

A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. [source]

And in that respect, there should be no need to standardize.

On the other hand, Markdown is so widely used that it’d be nice if there were some consensus around how to “do” certain things with/in it. That being said, aren’t most of the “problems” just a result of trying to do complicated things?