(Thanks Lasse.) Corporate performance reviews are for the most part a waste of time. At my last job, I worked with the same set of peers for around four years, and we did peer reviews on their anniversaries. The first year, I tried to provide constructive feedback on how I thought people were doing, what they could do better, etc. The second, third, and fourth years, I had no idea what to write. Reiterate what I wrote the year before? Try to comment on what they were doing better than they did last year? I didn't have a clue. Once (with a really cool boss) I wrote my evaluation as a limerick.
This article discusses what's wrong with reviews, and how they can be better. First of all, just bail on the idea that reviews can ever be objective, any more than journalists can. Then focus on the future, not the past. It's a very agile idea. I'm excited about the future of work. I think corporations of the 21st century can work so much better. But how many companies are willing to give it a shot?
Ramblings of a software developer with a degree in bioinformatics. Agile development mixed with DNA sequencing - what could go wrong?
Tuesday, February 28, 2006
Saturday, February 18, 2006
Coding Standards and Reviews
At the IQAA on Thursday, there was a good presentation on coding standards and reviews. I've always had a strong sense that code reviews were important, but I've never actually been to a code review that was worth the time it took. My current job has a standard requirement that all code should be reviewed, though, so I've sort of been casting about for a good style of review. Ed Gibbs has thoughts on the subject; so does Macadamian. But I definitely thought that as far as my company was concerned, Robert Bogue's talk got to the heart of what a code review should be. Not that we'll actually change our process, of course, but at least I'll have some talking points when the subject comes up :) (I'm a touch underutilized in my company, I feel. I have to persuade rather than insist. Maybe after another year or two.)
So here is what I took away as the most salient points:
So here is what I took away as the most salient points:
- Code reviews should not be painful. Bring cookies; have balloons.
- Code reviews should have a point. Don't just bring everyone in and show them the code. Then they all say, "um, sure, looks good." Have points of emphasis; exception handling, say, or readability.
- It's OK for junior developers to comment on senior developer's code. I'm still groping on this one; not that I ever thought that they shouldn't, but the question is more, how do you get them to do it? I've known developers that come to code reviews, sign all the forms, but then don't ever say a word about the code. I brought the question up at the time but didn't state the issue as clearly as I would have liked.
- Code reviews and code standards are related. This one had never occurred to me before, even after, at my last job, I wrote a short article called, "How to get your code past a review". Now I realize that that document was actually a coding standard. I think we've got a coding standard around somewhere at this company, but I'm not sure where it is. I'll probably resurrect it at some point.
So it was definitely a learning experience for me, and hopefully a springboard to learn more about the subject. Mr. Bogue has a blog as well, subscribed!
Tuesday, February 14, 2006
Yahoo! Patterns
Wow, this is a handy little pattern library. (Thanks to Grady Booch.) I'm spending more and more time with Yahoo these days, for stock updates, Yahoo! Answers, Flickr, and other things. A good sign for them, I guess.
Monday, February 13, 2006
The irrelevant Joel Spolsky
For a guy who has written so much good stuff on software development, I think Joel is falling behind the times. His latest post talks about not being able to find an online calendar that he likes, which is fine - I don't think anyone has, yet - but then he uses that as a springboard to decry the new software technique that he refers to as, "Ship early and often".
I did a web search for that phrase to find an alternate viewpoint, and Joel is already in the top three sites for it; he's quite an influencer. But he seems to have a lot of disagreements with the techniques of agile programming, which includes this technique, there referred to as "Frequent Releases". Joel - and the article I linked - claim that releasing half-baked software isn't a good idea; true enough in itself, but I'm guessing that the calendars he checked out weren't buggy, bugs are bad things and no one wants to use buggy software, but that they simply didn't have all the features he was looking for. Releasing a calendar that has actual business value isn't releasing half-baked software; it's getting something out there that people can use, evaluate, give feedback on. It's a starting point for a conversation with the users. Look at Flickr; the most popular photo-sharing site on the planet started its life as a game tool, and evolved into its current incarnation by listening to the users and giving them what they want. That's how you create software.
"But", Joel says, "I'm not going to look at 30 Boxes again -- I've spent enough time evaluating it." He won't be back to see next week's version, or even next year's. (I wonder what calendar program he'll be using in the meantime?) I suspect he says this as a recognized authority on good software, in the belief that if he doesn't like it, it's probably not much good. That's probably true, too, but, there are one heck of a lot of other folks out there. They have blogs. They write about stuff they don't like too, and they also write about stuff they do like, if not nearly as often. I didn't look at any of these Ajax calendars at all, myself. But eventually, I suspect, one will turn out to rock the world, and at that point it will be all over Technorati, Icerocket, Memeorandum, Tailrank. At that point I won't care about Joel's opinion of them today. Joel probably won't either. When one of them wins out, he'll know by word of mouth, as we all will. Two or three of the others will have fallen apart by then, spending too much time writing features that no one wants, not getting anything released out on their website, not getting any buzz. And that is why, if you're writing software today, you should release early, and you should release often.
I did a web search for that phrase to find an alternate viewpoint, and Joel is already in the top three sites for it; he's quite an influencer. But he seems to have a lot of disagreements with the techniques of agile programming, which includes this technique, there referred to as "Frequent Releases". Joel - and the article I linked - claim that releasing half-baked software isn't a good idea; true enough in itself, but I'm guessing that the calendars he checked out weren't buggy, bugs are bad things and no one wants to use buggy software, but that they simply didn't have all the features he was looking for. Releasing a calendar that has actual business value isn't releasing half-baked software; it's getting something out there that people can use, evaluate, give feedback on. It's a starting point for a conversation with the users. Look at Flickr; the most popular photo-sharing site on the planet started its life as a game tool, and evolved into its current incarnation by listening to the users and giving them what they want. That's how you create software.
"But", Joel says, "I'm not going to look at 30 Boxes again -- I've spent enough time evaluating it." He won't be back to see next week's version, or even next year's. (I wonder what calendar program he'll be using in the meantime?) I suspect he says this as a recognized authority on good software, in the belief that if he doesn't like it, it's probably not much good. That's probably true, too, but, there are one heck of a lot of other folks out there. They have blogs. They write about stuff they don't like too, and they also write about stuff they do like, if not nearly as often. I didn't look at any of these Ajax calendars at all, myself. But eventually, I suspect, one will turn out to rock the world, and at that point it will be all over Technorati, Icerocket, Memeorandum, Tailrank. At that point I won't care about Joel's opinion of them today. Joel probably won't either. When one of them wins out, he'll know by word of mouth, as we all will. Two or three of the others will have fallen apart by then, spending too much time writing features that no one wants, not getting anything released out on their website, not getting any buzz. And that is why, if you're writing software today, you should release early, and you should release often.
Friday, February 10, 2006
Generics at user meeting
I went to the Indianapolis .Net User Group meeting last night. They advertised Generics as the topic, and since I really didn't know anything about them, I was looking forward to it.
It turned out to be more interesting as a group dynamic than as a presentation. As a presentation, what I gleaned was that, from a user's perspective, generics are precisely identical to C++ templates. You declare a variable of a type that takes generics, and drop the specific type after the type name, in brackets: ArrayList foo = new ArrayList. Or you declare your own class and declare a after it to create your own generic.
From an implementer's standpoint, they're pretty darn different from C++ templates, as you might expect. And working out exactly what those differences might be engendered more discussion from the group than any topic I've yet seen. People were interested in how they were implemented, whether they would really avoid boxing, whether it was done at run time or compile time. There appeared to be two or three people who really knew their stuff, too - they were discussing what the IL that was generated looked like and that sort of thing. By the 45 minute mark, I was pretty sure that I was in for a two-hour or more night.
But amazingly, the entire presentation couldn't have been more than 35 minutes. Add in 25 minutes of discussion and the whole thing would have been over with before seven with plenty of time to draw door prizes and be out of there by 7:30.
But I don't know if that's what happened or not. The Q&A period was still going strong at 7:05 and I decided to bail. I hope my ticket didn't win a new car or something :)
It turned out to be more interesting as a group dynamic than as a presentation. As a presentation, what I gleaned was that, from a user's perspective, generics are precisely identical to C++ templates. You declare a variable of a type that takes generics, and drop the specific type after the type name, in brackets: ArrayList
From an implementer's standpoint, they're pretty darn different from C++ templates, as you might expect. And working out exactly what those differences might be engendered more discussion from the group than any topic I've yet seen. People were interested in how they were implemented, whether they would really avoid boxing, whether it was done at run time or compile time. There appeared to be two or three people who really knew their stuff, too - they were discussing what the IL that was generated looked like and that sort of thing. By the 45 minute mark, I was pretty sure that I was in for a two-hour or more night.
But amazingly, the entire presentation couldn't have been more than 35 minutes. Add in 25 minutes of discussion and the whole thing would have been over with before seven with plenty of time to draw door prizes and be out of there by 7:30.
But I don't know if that's what happened or not. The Q&A period was still going strong at 7:05 and I decided to bail. I hope my ticket didn't win a new car or something :)
Wednesday, February 08, 2006
ISO
I wrote a while ago about how ISO can actually be used as a positive thing for a company, which I suppose most developers at the grunt level would disagree with. It's true though: you just have to use it to describe your processes, rather than prescribe them.
There is a basic dichotomy, however: The company management may not have the least interest in improving the processes. They just want the pretty sticker for the front door that says, "Yes indeed! We're ISO approved! You can do business with us!" After that, they may not give a fig whether or not the processes are actually being followed, except to the extent that they won't get into legal trouble. This is why so many developers hate ISO. For ten months out of the year, they're told to bypass, sneak around, don't bother with the process, we have to get those customers happy. Or if they follow a process, they may get penalized for it. "What do you mean it'll take you two months to do that? We can't put that on the form! Put down three weeks!" Then, of course, when it does take two months, everyone has to work overtime since the project is so far behind schedule.
For the other two months of the year, they're told, "OK, here's the process. You have to have it memorized. If an auditor comes by, make sure you have the document in front of you. Just read it to the auditor. Don't make trouble. Don't volunteer anything. We just want our little sticker; we don't care about the process."
It's a shame. There's real value in ISO. I wonder if there are any companies that can find it?
There is a basic dichotomy, however: The company management may not have the least interest in improving the processes. They just want the pretty sticker for the front door that says, "Yes indeed! We're ISO approved! You can do business with us!" After that, they may not give a fig whether or not the processes are actually being followed, except to the extent that they won't get into legal trouble. This is why so many developers hate ISO. For ten months out of the year, they're told to bypass, sneak around, don't bother with the process, we have to get those customers happy. Or if they follow a process, they may get penalized for it. "What do you mean it'll take you two months to do that? We can't put that on the form! Put down three weeks!" Then, of course, when it does take two months, everyone has to work overtime since the project is so far behind schedule.
For the other two months of the year, they're told, "OK, here's the process. You have to have it memorized. If an auditor comes by, make sure you have the document in front of you. Just read it to the auditor. Don't make trouble. Don't volunteer anything. We just want our little sticker; we don't care about the process."
It's a shame. There's real value in ISO. I wonder if there are any companies that can find it?
Subscribe to:
Posts (Atom)