afongen

Sometime in the ’80s, my sister had me scouring record stores in the Twin Cities for a copy of Bing Crosby and David Bowie singing a duet of “Little Drummer Boy” that she wanted to give to her friend for Christmas. I never found it. A few years ago it turned up on a holiday sampler from Martha Stewart, of all things, and I’m sure can be found elsewhere.

Now we have YouTube.

Here’s the story behind the duet. Kinda cool. And that Martha Stewart CD has a couple other gems. Emmylou Harris just kills “The First Noel.”

At work we just had a couple project retrospectives, which the more depressing among you might know as as post-mortems. I usually try to avoid that term, but it might have been appropriate in this case. They came way too late and were run differently than I would have hoped, but that’s not the end of the world. We cope. At least we’re having them, right Mr. Bright Side?

To prepare, I skimmed through everything I’d written about the project on a private blog I keep at work. Just one of the many positive uses I’ve found for that blog, although it did leave me in a bit of a bad mood, which wasn’t how I’d have liked to go into the retrospective. Oh well.

Unfortunately, in my private blog I’d failed into mention something I wrote here, about a misapplication or misunderstanding of the idea of iterative development.Pity. That would have been useful.

Show you how up on things I am. Seattle got pounded by a hell of a wind storm last week and is just now getting power back. Uh, Chris? Check in.

A recent conversation made me realize how easily a mismanaged iterative development cycle can become a waterfall.

Break work out in stages, fine. Use those stages as short iterations with scheduled releases, building toward a final release of a “finished” product, good. Build on what you learn during those iterations to progressively refine your understanding of the requirements and your design, good.

Uncover important requirements and/or significant design flaws in early stages, but explicitly label these findings as “new features” that won’t be implemented because you didn’t know about them during the Big Design Up Front and now you don’t have time… not good. You’ve just missed the point and lost the advantage of iterative development.

It’s not enough just to know that requirements will change during development: you should act accordingly and build your process around the expectation of change. When requirements change (and they will), but you respond as if they have not and must not, then your process is broken.

We had a “town hall” meeting today to discuss the MnSCU ITS workplan for the next year. It was only hours later that I realized that it didn’t follow an all-too-common pattern of telling us a whole bunch of new stuff that we could have got in email. Instead, a PowerPoint overview was distributed beforehand (the narrative version is being written next, otherwise I hope that’s what we would have got), and knowledge of the contents was just assumed during the meeting. This opened up the meeting for discussion.

Marvellous. I am no fan of using meetings to disseminate information, so this is a very welcome change.

Jon Udell shares a sadly amusing anecdote about the sort of thing that gives PR flacks a bad name.

I share this not only because it’s sad and funny, but because it means Jon’s likely to write about GData. I’m looking forward to that, because I have a hunch that GData will be important. Stephen O’Grady explains why in far more detail than I have time for, so just go read that. Or since they’re having problems with their web host, read a cached version. Fundamentally, a relational database isn’t always the best solution for storing and manipulating data, and as Adam Bosworth has argued, we need new ways to access/manage our data in its various stores. GData, an Atom-based format, is a step in that direction.

I’m taking a more active role in the direction of my career, moving it in new directions, and I think it’s time for a retrospective.

Until a few years ago, I worked on a team that supported primarily department web sites (for the Office of the Chancellor at Minnesota State Colleges and Universities). I thought of myself as mostly a backend guy: PHP and mod_perl web development, Apache and MySQL administration. The others on my team did more direct support of department users. Or so I told myself. In retrospect, I did a lot more user support and was more closely connected to the front end than I believed. I was (am!) still the web standards advocate leading the way in CSS adoption. I was (and am) the accessibility guy, leading accessibility instruction for our college & university webfolk and even faculty. I don’t say this to toot my own horn, but rather to highlight that even though I thought of myself as a backend developer, I was very closely tied to the user experience. Certainly my Java programming colleagues on the other web team in the office knew this, but they readily admitted to hating HTML, CSS, and JavaScript, so were eager to find someone who gave a rat’s ass about that side of the work.

Not much has changed, come to think of it.

When my position got shifted in a reorg and I got moved onto the Java team working on enterprise web apps, I became the UI guy. On a team of Java programmers, most of whom were new to web development, this made sense and it’s a role I readily took up. Our web apps look like crap. They could use some updating. The team structure was a mistake: hiring began before our supervisor was brought in to weigh in on skillsets that we needed for web development, so we ended up with a team who all think of themselves as Java programmers instead of web developers. Sure, they’re smart people and decent programmers, and maybe web development isn’t rocket science, and I mean no disrespect to my coworkers, but geez it makes a difference in the quality of apps you produce. But I’ve already written about that and will write more.

My role right now is primarily defining the user experience. I work with business analysts and stakeholder groups to spec out the user interface and application flow, and help the developers work out the annoying details like how to do something with JavaScript or CSS. It’s fun work. The past year or so I haven’t been too involved in much coding — and that’s okay, since I’m not a huge one for JSP and my feelings about Java as a web development platform are known and not favorable. :)

Another part of my role that I’ve been trying to expand is web application security. So far there aren’t a whole lot of people pushing very hard to make it part of my job, but that situation is improving.

What’s missing is a connection to education. No student contact, although I’ve been working on software for student services. I don’t feel a connection to online learning, to educational technology … I’m privileged to be a part of an educational system: I grew up wanting to teach and still want to be involved in education, but really I’m not. Organizationally we’re divided sharply between academic and administrative systems, and I’m on the admin side. I hope that distinction will blur, that we can put development resources more directly toward educational goals, but we’ll see.

A recent meeting also made me realize that I feel out of touch with open source software. I’ve taken it for granted. Almost everything I work with is open source — web frameworks, JBoss, Eclipse, LAMP —. Some of that has been a struggle, and and it’s easy to forget the struggle and overlook when open source isn’t even on the table in places where it makes sense: data warehousing, content management systems. (Actually, I didn’t overlook open source in the CMS question, I threw up my hands in disgusted exasperation after six years of inaction.) Anyway, open source is making inroads into our colleges and universities, and I want to find a way to be a part of that.

I feel like I did in college, when I spent an ungodly amount of time wrestingly to unify courses of study in French, historical sociolinguistics, religion, and medieval history. I want to bring together web standards/user interface/user experience, dynamic languages, agile software development, open source, educational technology, and security, all while still trying to do the day-to-day work necessary to get software out the door.

Which we barely do, but that’s another story.

Sometime in the last few months, it struck me that I haven’t been taking active charge of my career, I’ve just been going wherever events have taken me. That’s not entirely true, of course, since I did get the hell out of my HR job when I realized that it was being pushed in a direction I didn’t like. I don’t want to just float along anymore.

I have decided that if I need a focus in my career, it won’t be user interface. It will be security. Through everything I’ve done, that’s been a common thread. As I mentioned here a short while ago, software security is a big problem, the elephant in the room that is partly responsible for what Noam Eppel describes as The Complete, Unquestionable, And Total Failure of Information Security. At MnSCU, we’re taking steps in the right direction toward improving software security, but we can always do more. I’m running up against a wall in what I can do as a single developer to infuse security into our software development life cycle. I can work from the bottom up, but I’m realizing that we also need to work from the top down. Secure development should flow from and be traceable to policy, to help identify standards and establish metrics. But all the policy and best practices in the world won’t help if the developers don’t know how to write secure software, and the architects don’t know how to, well, architect with security principles in mind. We need to approach the problem from both directions to be successful.

My secret goal over the next few months is to lay the foundation for more of that top-down software security work, while continuing to push more aggressively up from the bottom.

And in terms of professional development, I may well pursue more schooling. I have a lot to learn.

So expect a lot more writing about security here. Along with everything else, of course. Plus ça change…

Kiara just told me that she was talking with some kids who regularly watch Smallville, and had no idea that Clark Kent becomes Superman.

Just had to share.

So I should explain the Hughtrain cartoons. Just so we’re clear, I’m not quite as bitter as you’re about to think I am.

I work in IT for a large public higher education system.Not long ago I had a revelation that almost all the technology innovation I see at work isn’t happening in IT. Instead I see it coming from a few people in particular within Academic and Student Affairs who push for tech innovation to support the educational mission of the system, often introducing technology themselves because IT is out of touch. I realize that some of this is because ITS at MnSCU has been pathetically underfunded and can barely manage skeleton support and subsistence. And I’m not being entirely unfair to my IT colleagues: I said almost all technology innovation. But still.

You might picked up on it here if you’ve been reading along the last couple years, but I’m more than a wee bit frustrated with a development process that strongly favors multi-layer committee approval of every damn little thing, and careful planning of work months in advance. See, we operate at the intersection of higher education and state government. This tends to slow things down a tad and quash any chance of doing anything even remotely cool or even useful.

There. I came out and pegged myself as a developer: I want to build cool shit. But it’s not really that simple. I keep thinking that we’re operating in a post-Cluetrain world, that the lessons have been absorbed and that people are clued into what’s happening with what’s been happening with web development the last few years [1], and reality keeps smacking me down. I am consistently disappointed by the caliber of the web apps we’re slowly churning out. Top-down, faceless, human-less “enterprise” development. Our intranet is stagnant, except it’s brand-new and public-facing. Unless we break free of what is pretty damn close to a waterfall method, we’re screwed. I believe that we’re committed to doing a good job, I just don’t think that many of us are all that interested in doing a totally fucking amazing job.

But hey, that’s me.

I still have hope of sneaking something in. I’m finding ways to push the confines of narrowly defined use cases that still meet the specs and that make the apps better. And at least I’ve started telling my coworkers that I think it’s our job to write kick-ass apps — or rather, apps that help users feel like they kick ass. I’ve obviously been brainwashed by Kathy Sierra. Thing is, she’s right.

Pity no one liked my idea of running the student housing application as a first-person shooter. Just as well, I don’t think that the oughta-be-Quaker in me would be comfortable with the violence. I wonder if anyone will bite at running registration like fantasy football? :)

There. Now I’ve pegged myself as a developer and completely loony.

[1] – i.e. Web 2.0 — yes, I use the term willingly. Now you know I’m loony.

I was in a boring meeting and killed time by jotting down a list of books that I’m either reading now or plan to read in the next couple weeks.

• Ruby for Rails by David Black. You can’t get far in Rails development without knowing Ruby well. This is a good introductory Ruby book that goes into more detail than you’d expect and still comes off enjoyably readable. Glenn Vanderburg talks about the notion of using Rails not as a framework or domain specific language for web applications in general, but as a DSL for your web application. If you understand Ruby well, and you understand how Rails ticks, you’re on the way to doing this.
• A Little Ruby, A Lot of Objects. I’ve mentioned this before. A good way to grok OOP, Ruby style.
• Programming Ruby. The PickAxe is the standard with good reason.
• Best of Ruby Quiz. A language’s syntax is the easy part. To become proficient, I need to use a language to solve real problems, feel my way around the idioms.
• PHP 5 Objects, Patterns, and Practice. I’ve been itching to get back into PHP programming, and I immensely enjoyed this book’s practicality and clear-headedness. I don’t think anyone does a better job writing about PHP than Matt Zandstra. If you want to understand OOP in PHP, both from a mechanical/syntactic perspective as well as design philosophy, this is a very good place to begin.
• Facts and Fallacies of Software Engineering. My introduction to Robert Glass’s work, I return to this book periodically as a touchstone. Grounded in years of research and practice, Glass discusses what ought to be common knowledge but often isn’t. We keep making the same mistakes and we need to be reminded of that so we can do better.
• Software Conflict 2.0, again by Robert Glass. A collection of essays from 1990, still very much relevant.
• Rising Stars, vols. 1-3. J. Michael Straczynski wrote a comic book series? It is marvellous, as you would expect from the man who brought us Babylon 5. (Actually, he’s written more than one comic, but I really like this one.)
• How to Break Web Software. This is aimed more at software testers than I expected, which was a foolish assumption on my part. A good book. Oh, which reminds me, I need to reread the OWASP Guide 2.0.
• Software Security, Gary McGraw’s latest, focusing on building in security throughout the development lifecycle. I’ve come to a point where I need to start suggesting policy and practice. There aren’t many better places to start than Gary McGraw. I am also eagerly awaiting Michael Howard and Steve Lipner’s upcoming book about the Microsoft SDLC: The Security Development Lifecycle.
• Getting Real. Nothing new if you’re familiar with 37signals and their philosophy, but an engaging and exciting read. I find myself listening to Jason Fried over and over again.
• In the Company of the Courtesan. I heard an interview with the author and got sucked in.
• Shooting the Thorn Tree. Kiara’s Masters thesis. Well, one of them.
• Designing Interfaces. Yes, I am the user interface guy on our team.
• My Job Went to India. I’m not afraid of my job being outsourced, but I have been too complacent in driving my career. Time to take control.
• The Career Programmer: Guerilla Tactics for an Imperfect World. Cuz man, things get nuts.
• Beyond Code. See above.
• Spies Among Us. The local OWASP chapter discussed this last month but I couldn’t attend the meeting.
• Digital Identity. Phil Windley’s high-level discussion if identity management. I really, really need to wrap my head around what’s happening in this space.
• The Great Transformation: The Beginning of Our Religious Traditions. Karen Armstrong’s latest.
• Garth Nix’s Abhorsen trilogy. Have I mentioned that I’m a sucker for teen fiction?

Okay, got to get cracking.