Developing – Seite 3 – Here Be Subtlety

Many Browsers and a Smarter Playlist

Today at work a colleague raised the issue of which browsers we were planning to support. Naturally, supporting a browser also means testing on a specific version of a specific browsers, which, quite simply put, means more test effort, probably more coding effort, and therefore more time spent.

After a discussion with our product owner they settled on the latest stable version of four browsers. The product we were working on before supported two browsers, Internet Explorer and Firefox, with Internet Explorer being the one to optimize for, especially since one of the third party products only supported IE. Now we added Chrome and Safari to the list.

The same colleague also complained that he currently uses three browsers, sometimes simultaneously. I realized, I do too.

On Vista I use Chrome for most things. Now I know that it lacks the tons of add-ons that Firefox offers, but I just love it. I love that the design is very simple and focuses on the actual web pages rather than menu and status bars. Mostly I love typing in anything into the address field. I’ve gotten so used to it that I forget that other browsers use extra fields for Google searches and just typing my search words into IE’s or Firefox’s address bar. If there’s one thing I need other browsers to copy from Chrome, it’s this.

However, I understand that people still prefer Firefox. The fact is that I have never actually been an avid user of add-ons. I’ve had my favorite Firefox add-ons, mostly webdesign stuff like the color picker or the ruler and these were awfully helpful and cool. FireBug as well is an awesome tool for web developers. But I’ve never heavily relied on any add-ons which might have been the reason why switching to Chrome went so smoothly for me.

I still use Firefox occasionally, though, mostly when I need one of the add-ons I have installed or whenever a page doesn’t look quite so right in Chrome (still happens).

I use IE mostly for anything that relies on using IE, which sadly happens often enough. Now, I’m not even sure whether there’s still reason to hate IE (given that we’re two versions away from IE 6 it seems like the grunting phase should be over), I just still prefer Firefox and probably wouldn’t use IE if it wouldn’t rock the whole Outlook webmailing thing and wasn’t necessary to run some of Microsoft’s web applications (yes, MS Project, I’m looking at you). Plus, of course, given that IE is still widely used, it’s the browser I most often use when developing.

What I’m trying to say is that it’s gotten hard to settle for one browser, for three reason. First, sometimes you just can’t. Some pages or web applications just run or look better on a specific browser (and some will only run on a specific browser). Second, browsers seem to have their own personalities. Chrome is awesome for the whole browsing, social, fun, interactive stuff and in my opinion just generally awesome. Firefox is great because of its vast library of add-ons and because it’s really really good. IE still beats other browsers for some of the more conservative sites, probably because a lot of sites are still optimized for IE.

Last of all, the feeling I have is that all major browsers are actually getting pretty good, so there’s not a clear winner anymore. For most people that just means that they can just pick what they like best. For a geek girl like me it means that I can’t even settle on one for good.

In other news I fixed a small thing that was bugging me on iTunes. I like listening to my recently added items, but since I use my iPod for audiobooks and movies as well, these files were always mixed in between, which is especially annoying when you’re on your kickboard on the way to the train and don’t have the time to fiddle with your iPod just to skip that audiobook chapter or that episode of House.

Now, I could have realized that sooner, but of course, „Recently Added“ is just another Smart Playlist and perfectly editable. The only change I had to make was filtering it down to media kind and everything was as I wanted.

Scrum 101 – First Thoughts

We’ve been working with Scrum for a few month now and so far it has been a very interesting few months. For all of you who don’t know what Scrum is, here’s the gist:

Scrum is what you might best describe as a framework for agile developing. The reason why I’d call it framework is because it doesn’t so much tell you how to do things, but it provides a set of rules and roles that surround the actual developing. The key of Scrum is the team itself, which is self-organizing. Development cycles are usually two to four weeks. At the beginning of each cycle or „sprint“ the team commits to deliver a certain set of user stories, then works on these stories and holds a sprint demo at the end of each cycle to present their results to whoever is interested.

There’s tons of information about Scrum on the internet, so if you want to know more, you can either ask me or use your favorite search engine.

What I learned in these past months is that there are a few key things that you and your team need for Scrum to work. One of them is transparency. The other one is discipline. If one of them is missing, you might just be heavily screwed.

When I said transparency, I could have just as well said communication. It sounds so clichée, but communication really is the key. I still like transparency better because it sums up nicely what Scrum is really about and good communication is the way to reach transparency. I don’t think you can have one without the other. Or, okay, you can communicate without actually being transparent. However, I don’t see how you get transparency without communication.

When you start working in a self-organizing team, stuff gets lost. It just happens. All the time. We’ve identified communication (or the lack thereof) as one of our key problems after the first sprint and we’re still working on improving ourselves. It’s surprisingly hard.

Which leads right to the other thing: discipline. It sounds so school-masterly, but it’s true. I’m not talking military drill discipline here, just a healthy dose of get-your-crap-together. Because truth is, if you don’t, the rest of the team will suffer for it. The lack of a team lead means that the team is responsible for what they do. There’s no single person in charge or responsible.

To be honest, it is kind of scary at times. Self-organizing sounds so cool in theory and it is kind of cool in practice. It has its drawbacks though. When there’s nobody to tell you what to do, there’s also nobody to tell you what not to do, what better to do or how to do what you do. The team has to figure out how to finish their goal and often that’s not as easy as it sounds.

When I talk about discipline in Scrum I’m talking about doing the best you can to get your tasks done. But more than that, I expect you to always think about what needs to be done to get everything delivered with the best quality possible. I expect you to not ignore any problems in hopes that they go away if we don’t talk about it. I expect you to think outside of the borders of the taskboard. Also, in times of increased crankiness, I expect you to suck up and be nice. We all have bad days.

Discipline doesn’t mean working non-stop cranking out code. It also doesn’t mean sticking to fixed rules and doing everything by textbook. And it should never ever mean not having fun.

Working in a self-organized team requires communication, transparency and discipline, because as a team member I depend on the rest of the team. In short: I need to trust my team to be able to work effectively. So I’d like to add trust as another key word for Scrum teams, but that’s a story for another post.

Coding Nostalgia

Jeff Atwood over at Coding Horror wants to know where all the COBOL programmers are.

Well, one of them is sitting at her computer typing this. To be fair, I haven’t written any COBOL code in more than four years and even when I did I wasn’t that enthusiastic about it. But still, I did my apprenticeship in an IT company providing services for some of the major insurance companies in Germany, so guess what language all their programs were coded in?

Here’s a quote from Jeff Atwood’s article:

If these 220 billion lines of COBOL code are truly running out there somewhere, where are all the COBOL programmers?

I think it’s safe to say that a lot of them just ran. I didn’t exactly run from COBOL and the fact that I wrote code in MUMPS after my COBOL gig probably is prove enough, but I wasn’t sad to leave it either. However, it might have been one of those experiences that in retrospect don’t seem that bad and leave you with that superior feeling of been there, done that.

COBOL is indeed a strange language, and to those who are not familiar with its strangeness, here’s a quick introduction to its weirdest character traits.

Fixed divisions and sections. Start with the IDENTIFICATION DIVISION, move on to the ENVIRONMENT DIVISION with its INPUT-OUTPUT SECTION, then on to the DATA DIVISION to define yourself some fancy variables. Only then can you start writing actual code in the PROCEDURE DIVISION. It’s kind of awesome and insane at the same time. You can’t mix up any of the divisions, there’s a fixed order and you can’t define your variables anywhere else than in the DATA DIVISION.
Defining variables itself is a blast. First, you have to define them all upfront, which is not that unusual, but still. Second, you have to set a size. I mean really set a size. Like, this is a string and it’s 30 characters long. This is an integer and it’s 6 digits long. This is a freaking decimal and it’s 4 digits and two decimal places. No re-defining during code. I think apart from the fact that COBOL doesn’t provide a modulo operation which left me with no choice but naming a variable „USELESS“ once1, this was the part of COBOL that annoyed me the most.
This doesn’t have to do with COBOL directly, but I’d like to throw in JCL. JCL – or Job Control Language – was a scripting language that could at best be described as cryptic and was needed to actually run the COBOL programs. I’m pretty sure that in the whole company there seemed to be only one guy who actually understood the language. Everyone else was doing it the copy/paste/pray way. Maybe I’m wrong, but that’s what it seemed like.

No, I don’t miss writing COBOL code. But maybe it was worth learning how to write COBOL anyway. First of all, I am one of those COBOL programmers. Plus, you can always tell one of those coding nostalgia stories at lunch and get that glassy look in your eyes remembering the time when you spent hours a day writing those copybooks. Good old days.

It’s even more fun though when you get me started on MUMPS. Because that, my friends, is one fucked-up language.

—

1How do you work around that? Well easy, you can use a division and the save the result and the rest. Unfortunately you have to store the result, which when you really only need to use the rest, doesn’t leave you with any choice, but to passive-aggressively name your variables the only way they can be properly described: useless.

Anticipating the Next Tile

In our development department we’re currently working with two teams to build a new product. The platform team – as you might be able to guess – is working on the platform, the framework or architecture, however you want to call it. The other team, the one I am in, is working on the features, building on what the platform team provides us with.

Splitting responsibilities the way we do makes perfect sense. We do have those gray areas where it’s not that clear whether something belongs to platform or might be a feature, but in most cases it is pretty clear what task belongs in what team.

There’s one downside though, and that is that because each team is working on its own tasks, communication sometimes has to be pushed a little to happen. Although we’re not working on the same tasks, we’re still working on the same product and even if I can’t interfere with how the other team is doing their job, it’s interesting for me to know what they’re doing and why they’re doing it.

I want to compare that to my old version of Tetris on Nintendo’s GameBoy (yes, the very, very old one) where on one side of the screen the next tile to come would be displayed. I distinctly remember that I deactivated that option, thinking that it wouldn’t change my game. I didn’t think that I even bothered to glance at that tile.

So, I did turn it off and… oh my god… I got so much worse! Without realizing it, I always noticed the next tile and some part of my brain clicked and made me integrate that information in my gameplay.

Why the comparison? I think that sharing information between teams works the same way. When I know what the other team does, what they’re currently working on, what they plan to deliver and when they plan to deliver it, I can take that knowledge and have it in the back of my mind while I go about my own tasks.

Knowing what another team does might not directly affect my work. I think this is also one of the main reasons why communication between teams may be lacking a bit: Since our work is not directly affected, information about what happens outside of our little feature realm seems like a nice-to-know thing. I don’t necessarily need it and it probably doesn’t change how I should go about implementing my feature right now.

Nor do I have the power to do anything about it if I don’t like it. Whatever the other team is working on will sooner or later pop up in my code anyway. As long as I don’t have a say in that matter, why would I want to know any details? (I might be able to mention my concerns and ideas, though. So that’s a plus as well.)

However, developing with new tools and technology brings enough surprises as it is. Eliminating what other surprises – even little ones – there might be as best as I can means that I can work more comfortably and confidently on my own tasks. It gets me out of the little vacuum of my team and reminds me that there is a world outside of the feature set currently implemented. And whatever happens in the future I might at least have heard of it before.