Archive for January, 2009
While My Schedule Gently Weeps
Wednesday, January 28th, 2009
It never fails, we can be in mid-Sprint, our task list decided on, our Product Backlog up to date, and out of the blue the client will hesitantly approach my desk. “I was wondering…how hard would it be to…”
At this point, any self-respecting programmer has disengaged her higher-order cognitive function and queued up the automatic “mid-Sprint” answer: “I’m not sure. We’ll add it to the backlog and estimate the effort in a future iteration”.
She does this not out of callousness, but out of respect for the greater good of the process. If she allows her flow to be interrupted and derailed by an “out of cycle” request, she’ll be doing the team, the schedule, and ultimately the client a disservice.
Not me. That phrase – “how hard would it be to…” — that budding client request — triggers in me the Pavlovian response of “Sten the Can-Do Problem Solver No Matter What I’m Currently Doing, At Your Service!”
Innocuous or not, this phrase is a trap by clients to wedge work into the Programmer Flow — an attempt to get “free work” without estimation. I don’t know of any Agile or eXtreme methodologies that advocate “drop everything and do whatever the client says”, but I fall for it every single time. I’m more than happy to circumvent any established process, no matter how Agile and flexible for the sake of People Pleasing and Immediate Problem Solving Gratification.
client:”Sten, how hard would it be to add some extra columns to that report we wrote four months ago? Remember that one? I just want to add a few, or so, or 10 extra columns.”
me:”Um…we should probably…add it..to the to-do list–”
(And then he brings out the bait)
client:”Oh of course, I figured it was too difficult to do right now. That’s a shame though…”
me: “Well it’s…not necessarily too difficult, I just–”
(And then the Mega-bait comes — the client’s attempt to solve the problem himself, usually by referencing random UI elements).
client: “No, you’re right, we should wait. I imagine it will involve adding some more checkboxes, and possibly a button or two”.
me: “No! No! No that’s not– Fine! OK! I’ll do it! Right now! I can do this, it’s not a problem”.
I don’t know why I’m such a sucker, but every time it– whoops, hang on, the client wants to talk to me–
A Radial Visualizer in the Wild
Wednesday, January 28th, 2009
Paul sends along a link to a group of visualizations found over at Eigen Factor similar to my recent JavaFX Radial Visualizer (similar, that is, in the same way that the Atlantic ocean is similar to the puddle outside of my house).
These visualizations are polished, very slick, and highly interactive (if a bit unresponsive at times). They were apparently created with Flare — that is, with the Flash visualization framework, not with fanciness.
Flash is the undisputed champion of data visualization on the web, but it would be nice to see JavaFX make some in-roads in this space. Jim Weaver reports that Ben Jones has been working on integrating charting capability into the JFXtras project (which is a great demo, if you haven’t tried it).
Perhaps JFXtras will have some room for some alternative or experimental visualizations in the future as well…
JavaFX Radial Tag Visualizer
Monday, January 26th, 2009
Building off the momentum of my previous Tag Visualizer, I decided to write another one, this time using a radial model.
The data is the same as before: tags from my tag cloud with their relative weights and correlations (how frequently they occur in the same post — the wider the line of the arc, the stronger two tags are correlated).
This visualizer scales much better than the previous one. I can easily fit my entire tag cloud, which, granted, isn’t all that big. So how well does it scale? Check out this screen shot:
This massive ball of twine represents the top 180 tags from Last.fm and a fraction of their correlations (here “correlation” means how frequently two tags are applied to the same band). The data is courtesy of Paul Lamere during his Open Research initiative.
So while it does scale better than the previous attempt, it certainly has a definite upper limit.
Similar to the previous visualizer, this idea was also taken from the Graphic Design book, “Data Flow”.
JavaFX Tag Visualizer
Monday, January 19th, 2009
Lately I’ve been experimenting with some of JavaFX’s animations to do some Data Visualization. Below is a screen shot of a little app that will visualize some of the top tags on my blog, much like my Tag Cloud widget does.
If you’d like to launch it and see some of the animations yourself, click the button below:
Similar to a Tag Cloud, the “dome” size is relative to the frequency of the tag (big domes = more tags). There’s an extra couple of bits of information in here though: the arcs that connect the tags represent how tags are correlated to each other. The wider the arc the stronger the correlation. So in the above screen shot, Java and Groovy are strongly correlated (they frequently appear together in the same post), whereas DSL and Groovy are weakly Correlated, and Swing and DSL aren’t correlated at all.
The data is canned at the moment, but in order to get a sense of what a different cloud would look like, here’s a screen shot with data populated from a blog by my fellow colleague Shane Johnson, an active blogger on WCM and the like:
The arcs are traced out via the new PathTransition class. In fact all of the animations make heavy use of the Transition API: FadeTransitions, ScaleTransitions, PauseTransitions, and even SequentialTransitions to keep everything together. These classes seem to be new to the 1.0 release (I don’t recall seeing them in the Preview), and they really do take a lot of the pain out of trying to programmatically manage an animation.
This was a fun experiment. It would be nice to pull from live data in the future, and perhaps even have a widget like this co-existing along side a tag cloud in a blog.
By the way, the idea for this type of visualization was taken from the excellent new book on Graphic Design: “Data Flow“.
First Ever Chicago Groovy User Group
Sunday, January 11th, 2009
The first ever Chicago Groovy User Group is meeting this coming Tuesday, January 13th at 6pm in the Chicago Loop. Details are available at http://cgug.org/.
I’ll be giving a talk on integrating Groovy DSLs into Java applications, focusing specifically on a project that I’ve recently finished.
There will be free food, and even a book raffle I’m told. If you live in the Chicagoland area, we’d love to see you there. Come for the Groovy, stay for the party.
I’m like a Hypochondriac, but with Programming
Tuesday, January 6th, 2009
I heard the following phrase no fewer than three times at a recent tech conference: “Bad Programmers will move heaven and earth to do the wrong thing”. The first time I heard it I thought that it was kind of catchy, maybe I even chuckled a bit with the others in the room.
The second time, a nervous smile crossed my face and I started looking around. By the third time, I was convinced that this quote was aimed directly at me: “Sten, you”, the presenter aimed his laser pointer right in my face, “will move Heaven and Earth to do the wrong thing”.
Other professions probably have their effective, less effective, and probably even negative producers, but for some reason, in software development this is a super heated topic. Look, we even have a Wikipedia entry for them: The NNPP, or so called Net Negative Producing Programmer.
In fact this very topic turns what by all other rights seem to be nice folks into vitriolic zealots. Many blogs I read, or talks that I’ve attended, will at some point digress into a commentary on their sub-par peers. Since these people seem to know the qualities of a Bad Programmer a priori, and I’m a little fuzzy on the subject, it leads me to believe that one (or both) of the following may be true:
- I have not yet had the pleasure (or misfortune) of working with a truly destitute programmer yet.
- I am actually one of the terrible programmers in question.
I don’t believe that the latter is true, however, even passing belief that it might be has led me on a never-ending crusade to determine if indeed, I suck.
It’s like Matt Damon said in Rounders: “if you can’t spot the sucker in the first half hour at the table, you’re the sucker”. If I look around and fail to see terrible programmers, does that mean I’m one of them? Am I blithely leaving a path of coding carnage that others are forced to clean up?
I don’t believe this is the case, but the frequency of hearing about NNPPs coupled with my anxious tendencies make me uncertain. So that is why whenever I stumble across yet another witch hunt for smoking out the bad seeds of programming, three way mixed metaphors notwithstanding, I break into a nervous sweat while I pour over the latest criteria of “You’re a Bad Programmer if…” with anxiety that should be reserved for waiting for thyroid test results from my doctor (re: thyroid, no worries, I’m fine).
This obsession has led me to do things like interview with Google, since they seem to have their share of smarties, so maybe some of their smarties could objectively evaluate me, even though I didn’t necessarily want to work there (retrospective note: should not have said during the interview, “I don’t necessarily want to work here”).
Joel Spolsky (and his ubuquitous book/blog “Joel on Software”) is in many ways the origin of this anxiety. Before I go any farther let me be perfectly clear: I adore Joel’s writing style, I eat it up as Software Gospel. Indeed, it was out of this adoration, that my quest for acceptance grew.
But Joel has no shortage of opinions about what makes a Great Programmer and what makes a steaming pile of programmer dung. Joel has written extensively on the subject in no fewer than three books including a guide to hiring the best programmers (which outlines exactly why you won’t be able to hire a great programmer. Answer: they are never on the market. Which, by the way, makes me wonder where consultants fit into his developer food chain since we’re on the market potentially several times a year, but that’s another topic).
In fact if you’re a Programmer Hypochondriac like me, you may be nervously scanning this post looking for assurance and validation from my own list of “Bad Seed Traits” so that you can breathe a sigh of relief when you see that “oh thank goodness, I write unit tests, I must not be One Of Them”.
I’m sorry to disappoint, but I have no insight into the Bad Programmer phenomena. Actually, at the moment, I’m more interested in looking at those who hunt them down.
Actually, it’s probably not much of a mystery. The realm of Software Engineering seems to have more than its share of Those with Strong Opinions.
If you doubt that programmers have strong opinions, be sure to check out the heated argument over at Coding Horror over a probability problem, as scanning through a couple thousand comments may convince you otherwise.
I don’t know if it’s that those with strong opinions naturally gravitate toward programming, or if arming someone with a bit of CS knowledge makes them this way (probably the former), but suffice it to say that I’ve seen friendships end over “inheritance vs. composition”.
When you couple strong opinions with a very low barrier to entry in the field, it’s only a matter of time before the the finger pointing and name calling start to emerge. (As a profession, doctors also have a high rate of Strong Opinions, but they have a much higher entry barrier including lots of expensive schooling, and emergency appendectomies at 3am. So one might say that they’ve “earned it”. Besides, it’s dangerous to compare us to doctors anyway).
But how much of this is legitimate criticism, and how much is just plain mean?
At one of the talks I attended recently the speaker encouraged us to figure out creative ways to shame programmers who did things like break the build. Really? We’re promoting shame now as a motivation tool? As in, we should take away someone’s dignity? The speaker told us that talk was intended as a venting session, but I walked away from it feeling spiteful and sad for our profession.
Don’t get me wrong; I’m by no means blameless. I compare myself to others all of the time, and it’s usually not satisfying enough to come to the conclusion that we’re all equal in our own special way. So I judge others’ competencies, in my own mind if nothing else.
It’s just that when I do, it always leaves me feeling dirty and antagonistic. It makes me protective over my own ideas and not a very good team player. So for me anyway, dwelling on trying to separate the Programming Wheat from the Chaff is unhealthy and leads to professional sadness.
“Dude, you don’t understand”, you say, “Bad Programmers are costing us millions of dollars a year and slowing down the Good Ones”. No, I get it, fine. I’m all for higher barriers of entry and accountability. I’m not denying the existence of NNPPs — in fact I would argue that we’ll all NNPPs some of the time. (Are we all positively productive on the first day of a new project?)
The problem is that there is a difference between a call to improve yourself and a call to quit and find other work, you’re hopeless.
Recent Posts
Archives
I’m Literate!
'to-read':