I've been with the development integration team for a little over a year now. The team had been around for a couple of years before I joined. A lot of the DI team's code is in scripts. And almost all of the scripts are in Perl.
Now this was a change for me. I hadn't looked at Perl in years. I dabbled with it a bit back at Core Networks like over 10 years ago. The truth is somewhere around 2001 I happily converted to Python and never looked back.
But I knew when I joined DI it is a Perl shop. There are a number of Perl developers in the office many of whom have common roots in previous companies to our current employer. All are over 30. I can say that the active Perl developers are technically sharp with good judgment. So if they used Perl extensively over the years and still actively use it then I know there's something there; it's good technology.
But with me Perl has taken some getting used to. The syntax just seemed to be hard to grasp. So I knew I needed to catch up. So I did some self education. I heard good things about Leaning Perl so I ordered it with my own money. The Llama book is a very good read. It presents the material in a very sensible way. It provides the key information to get rolling without getting sidetracked with being pedantic, weird and obsolete syntax forms, or going off on tangents. I definitely recommend Learning Perl to anyone finding themselves getting started on Perl development or maintenance.
It is useful the book is presented training style with exercises at the end of the chapters. These were quite valuable to work through as they force the reader to really better grasp what was presented by actually using it.
So finally I can properly grasp the legacy code and better understand what's going on. I gained some more respect for Perl from this book. There is a certain power with all of the shortcuts and special rules. Perl does have the ability to produce moments of satisfaction when working with it.
It's the kind of thing I think you need to be working with it pretty much every day. So lately I've found at work when I need a little script to do a bit of work I've been using Perl more just to get more ad hoc experience.
So the Llama is a good start. I'll let this absorb for a few months or so then start on some more Perl reading when I'm ready. I think Intermediate Perl would be a good next title.
Monday, November 28, 2011
Sunday, November 27, 2011
update
It's been a while since I've posted. I haven't forgotten about this site. I'm glad Google still knows about it and steers some visitors here. I still work in software and I haven't lost interest in programming and software development. I guess I ran out of things to write about.
So what have I been up to the last year and a half or so? Around a year ago I joined a new team at work. I now work in Development Integration (DI). It's kind of a support role for developers and QA. We still write code but not so much shipping product code. We aren't testers or automated test developers but we do support QA and automated testing and continuous integration. We don't own the builds but we work with development and the build teams to support builds. We aren't gatekeepers but we support the dev teams enlightened use of CM.
It's been a good move for me. My company is big enough that we can have separate teams that do development integration work. After over 14 years in the cubes as a heads down coder I was ready to try something new.
There have been two rounds of downsizings this year. Luckily I managed to survive both. These were the first RIFs since I joined back in 2008. I didn't write about them because I've written on that subject in the past and I didn't have anything new to say. I hope the company can get back on track and it will be more stable again going forward.
In my year with DI I have observed some things and formed some thoughts. So I have a couple of posts to do in the coming weeks.
So what have I been up to the last year and a half or so? Around a year ago I joined a new team at work. I now work in Development Integration (DI). It's kind of a support role for developers and QA. We still write code but not so much shipping product code. We aren't testers or automated test developers but we do support QA and automated testing and continuous integration. We don't own the builds but we work with development and the build teams to support builds. We aren't gatekeepers but we support the dev teams enlightened use of CM.
It's been a good move for me. My company is big enough that we can have separate teams that do development integration work. After over 14 years in the cubes as a heads down coder I was ready to try something new.
There have been two rounds of downsizings this year. Luckily I managed to survive both. These were the first RIFs since I joined back in 2008. I didn't write about them because I've written on that subject in the past and I didn't have anything new to say. I hope the company can get back on track and it will be more stable again going forward.
In my year with DI I have observed some things and formed some thoughts. So I have a couple of posts to do in the coming weeks.
Monday, March 22, 2010
happy trails Joel
My long time favorite tech blogger Joel Spolsky of joelonsoftware has now signed off.
It was a great site in its heyday. Thanks for the memories and great articles Joel! And the forums were great in their heyday, the hub for those programmers who "get it".
Alas, like a great TV series the writers "ran out of things to talk about" and the last years weren't as good as the first. It was indeed time to shut it down on the 10th anniversary. The later years were OK, but like Seinfeld nobody says that the last 3 seasons were near as good as the first three.
It wouldn't be cool to bring it up in the forums but I was thinking of when did Joel jump the shark? Was it when he started requiring log in to post in the forums?
For me it was the "very special Joel" when he had this wrenching ethics crisis about accepting freebies from site sponsors such as Peer1 hosting. And going forward he would voluntarily begin paying for these things that previously he quite openly admitted he was getting for free in exchange for the product placement on his popular site. The site just wasn't the same after that.
It was a great site in its heyday. Thanks for the memories and great articles Joel! And the forums were great in their heyday, the hub for those programmers who "get it".
Alas, like a great TV series the writers "ran out of things to talk about" and the last years weren't as good as the first. It was indeed time to shut it down on the 10th anniversary. The later years were OK, but like Seinfeld nobody says that the last 3 seasons were near as good as the first three.
It wouldn't be cool to bring it up in the forums but I was thinking of when did Joel jump the shark? Was it when he started requiring log in to post in the forums?
For me it was the "very special Joel" when he had this wrenching ethics crisis about accepting freebies from site sponsors such as Peer1 hosting. And going forward he would voluntarily begin paying for these things that previously he quite openly admitted he was getting for free in exchange for the product placement on his popular site. The site just wasn't the same after that.
Tuesday, March 02, 2010
4 in 17
At work I've expressed interest in being involved in the recruiting process. As it happens we're thinking of bringing in a co-op student for the January work term. My team leader remembered I'd expressed interest in recruiting and asked if I wanted to attend the phone interview.
I agreed and me and the lead manager went to a conference room to phone the candidate. He is not a local student.
The phone interview went ok. It was around a half hour. After the interview though I had my own decision. Maybe I shouldn't say my decision but instead I'll tell a story from the past which has always stuck with me.
Back at PRIOR around 10 years ago a co-worker was talking about a TUNS course. A TUNS prof lived on his street and he volunteered to mark the compilers course. He got talking about the students in the course. There were 17 students in that compilers course. The assignments were code heavy and my coworker got to see the code they were writing to mark it. It was a third year course and everyone who took it passed.
He commented on the course afterward. Based on the code they wrote, of the 17 students in that class only 4 were good enough to work at PRIOR. The other 75% weren't talented enough for PRIOR. [I believe 3 of the 4 did do at least a co-op work term at PRIOR as it happened and 1 or 2 ended up joining full time]
For some reason that has always stuck with me. 4 in 17. TUNS had a good reputation and a number of good grads came out of there and went on to successful careers both in graduate school and in industry. Still only about 25% even in a class like that were really good.
So in product development, you need to be patient and choosy in recruiting. It can be a challenge wading through unqualifieds looking for people who can come in and be reliable contributors. With co-ops better to leave a position unfilled than to bring in someone clearly in the other 13 of 17 just to fill it.
I agreed and me and the lead manager went to a conference room to phone the candidate. He is not a local student.
The phone interview went ok. It was around a half hour. After the interview though I had my own decision. Maybe I shouldn't say my decision but instead I'll tell a story from the past which has always stuck with me.
Back at PRIOR around 10 years ago a co-worker was talking about a TUNS course. A TUNS prof lived on his street and he volunteered to mark the compilers course. He got talking about the students in the course. There were 17 students in that compilers course. The assignments were code heavy and my coworker got to see the code they were writing to mark it. It was a third year course and everyone who took it passed.
He commented on the course afterward. Based on the code they wrote, of the 17 students in that class only 4 were good enough to work at PRIOR. The other 75% weren't talented enough for PRIOR. [I believe 3 of the 4 did do at least a co-op work term at PRIOR as it happened and 1 or 2 ended up joining full time]
For some reason that has always stuck with me. 4 in 17. TUNS had a good reputation and a number of good grads came out of there and went on to successful careers both in graduate school and in industry. Still only about 25% even in a class like that were really good.
So in product development, you need to be patient and choosy in recruiting. It can be a challenge wading through unqualifieds looking for people who can come in and be reliable contributors. With co-ops better to leave a position unfilled than to bring in someone clearly in the other 13 of 17 just to fill it.
Monday, August 24, 2009
Emergent behaviour in self organizing teams
In recent months I've been working within scrum. It's been a learning experience for me. I hadn't worked in this type of environment before.
An important aspect of scrum that has taken some getting used to is the self organizing aspect of it. Historically I've always been in a model where there is the team lead/project manager who hands out assignments to programmers, monitors progress, and then hands out the next assignment. Over the years I've been both the programmer receiving and carrying out instructions, and the team lead identifying tasks and distributing them to team members.
With scrum there's just the list of tasks and people just grab one. That can lead to some interesting dynamics. In a way it can lead to silos if people just do what they know and are comfortable and familiar with. Perhaps that's not necessarily bad. I think that the team lead (but more importantly the team itself) still has something of a role in self organizing in ensuring that less desirable tasks are distributed fairly and the more interesting work is also distributed fairly.
In self organizing teams different themes may emerge. One would be the classical concept of the "chief programmer team". Once thought to be an academic construct, this could emerge in a scrum type setting. Especially if an individual is a really outstanding developer. In that case you may find the others will take on secondary tasks so that the key developer's time is maximized writing code. Also the key developer may either explicitly or implicitly in the group take on the most difficult assignments and more routine assignments are picked up by the others. In that sense it optimizes the work load in a way that the traditional team leader/task distributor model cannot.
I didn't look into it so I don't know if there's a lot of research around on self organizing teams. In software specifically this has only really been strongly around for the last few years. So I think there's some opportunities there for social scientists to make their mark and study this emerging area. I think there's probably some interesting and perhaps unexpected observations to be made.
This might be a good topic for someone looking for an honors project in the social sciences. Hang out with a scrum team or two for a few months, attend the daily standup, retrospectives, demos, etc. See what you can come up with about the emerging group dynamic. This is quite doable at most universities (I'm talking about you Laurier) as there are always tech companies near to campuses. Another possibly interesting angle might be to correlate DISC scores and scrum team dynamics to see if there's any influences there.
An important aspect of scrum that has taken some getting used to is the self organizing aspect of it. Historically I've always been in a model where there is the team lead/project manager who hands out assignments to programmers, monitors progress, and then hands out the next assignment. Over the years I've been both the programmer receiving and carrying out instructions, and the team lead identifying tasks and distributing them to team members.
With scrum there's just the list of tasks and people just grab one. That can lead to some interesting dynamics. In a way it can lead to silos if people just do what they know and are comfortable and familiar with. Perhaps that's not necessarily bad. I think that the team lead (but more importantly the team itself) still has something of a role in self organizing in ensuring that less desirable tasks are distributed fairly and the more interesting work is also distributed fairly.
In self organizing teams different themes may emerge. One would be the classical concept of the "chief programmer team". Once thought to be an academic construct, this could emerge in a scrum type setting. Especially if an individual is a really outstanding developer. In that case you may find the others will take on secondary tasks so that the key developer's time is maximized writing code. Also the key developer may either explicitly or implicitly in the group take on the most difficult assignments and more routine assignments are picked up by the others. In that sense it optimizes the work load in a way that the traditional team leader/task distributor model cannot.
I didn't look into it so I don't know if there's a lot of research around on self organizing teams. In software specifically this has only really been strongly around for the last few years. So I think there's some opportunities there for social scientists to make their mark and study this emerging area. I think there's probably some interesting and perhaps unexpected observations to be made.
This might be a good topic for someone looking for an honors project in the social sciences. Hang out with a scrum team or two for a few months, attend the daily standup, retrospectives, demos, etc. See what you can come up with about the emerging group dynamic. This is quite doable at most universities (I'm talking about you Laurier) as there are always tech companies near to campuses. Another possibly interesting angle might be to correlate DISC scores and scrum team dynamics to see if there's any influences there.
Monday, May 18, 2009
Thoughts on software source code review
Code review is an interesting subject. Software history is littered with companies that began doing code reviews with the best of intentions. Then somewhere along the way they became discouraged and just gave up on code reviews.
Why does code review fail?
That's a good question. Most people agree that code review is beneficial. It catches bugs very early when they are extremely inexpensive to fix. Knowing that the code is going to be reviewed keeps "crap" code out as the programmer will be far less inclined to try to sneak in bad code if he knows he's going to have to answer to it. Code review can identify and correct subtle defects that can be extremely difficult for the test team to produce in a lab testing environment outside the field.
I suspect a lot of the problem is when code reviews take on a life of their own. Code review is governed by the 80/20 rule and 80% of the benefit is realized in the first 20% of time expended. After that the point of diminishing returns is quickly reached and it becomes quite inefficient and unenjoyable for all involved.
So the trick is to set it up to get that 80% of benefit quickly, the easy wins, then basically halt the review when it reaches the point of diminishing returns.
Well then why do they drag out? What happens during that last 80% of the time. I think this is where software companies that start doing code reviews get into trouble. The reason reviews take on a life of their own is that the purpose of code review is not well defined. Some see code review as a time for mentoring, coaching, showing the "better way", being pedantic and showing off reviewer skill, training less experienced staff.
What that relates to is that "crap" code turns out to be extremely subjective. Here's some examples of stuff in Java that I've seen sent back in code review for rewriting.
The reviewer sent it back stating that it be changed to
Here's another
The reviewer sent it back stating that it be changed to
This are examples of what I call Programming by Proxy. We have valid, working, maintainable code being sent back for rewrite. There's nothing wrong with the code as originally written, it works properly, the reviewer just wouldn't have done it himself that way so he demanded it be rewritten to the way the reviewer would have done it. Once programming by proxy becomes the norm then code review is well on the way to the trash heap of company history as a well meaning but failed experiment.
How to keep reviews on track
The answer to this is as simple as it is obvious. Impose discipline on reviewers. Specifically this: the only thing that is actionable in a code review is runtime errors. That's it, runtime errors only. Otherwise the code stands as written.
I know some people may at first recoil at that idea. Indeed it seems counter intuitive as you are losing the value of doing code reviews. But you aren't losing value. By focusing on runtime errors only you get the most value of the code review, positive changes to the code that will correct real user affecting defects. In the 80/20 rule 80% of the benefit of code review is elimination of defects. The rest is rewriting code that works which is of marginal benefit at best.
What about the crap code though? How do we keep that out if runtime errors are the only things reviewers are allowed to raise. There's a couple of counters to that. First of all by having to submit the code to review the programmer will be more inclined to check in good code if he knows for sure someone is going to see it. The way bad code gets in is when a programmer is working by himself with no guidance or oversight and never having to answer for his work; then he can become sloppy and take shortcuts. Simply knowing that the code will be looked at will prevent most of the crap code from getting in.
Also by utilizing the 80/20 rule the reviews will finish up so much faster. That way if the reviewer saw something in the review that he personally disagrees with (like the examples above), then the reviewer is free to go in there and fix it himself.
Why does code review fail?
That's a good question. Most people agree that code review is beneficial. It catches bugs very early when they are extremely inexpensive to fix. Knowing that the code is going to be reviewed keeps "crap" code out as the programmer will be far less inclined to try to sneak in bad code if he knows he's going to have to answer to it. Code review can identify and correct subtle defects that can be extremely difficult for the test team to produce in a lab testing environment outside the field.
I suspect a lot of the problem is when code reviews take on a life of their own. Code review is governed by the 80/20 rule and 80% of the benefit is realized in the first 20% of time expended. After that the point of diminishing returns is quickly reached and it becomes quite inefficient and unenjoyable for all involved.
So the trick is to set it up to get that 80% of benefit quickly, the easy wins, then basically halt the review when it reaches the point of diminishing returns.
Well then why do they drag out? What happens during that last 80% of the time. I think this is where software companies that start doing code reviews get into trouble. The reason reviews take on a life of their own is that the purpose of code review is not well defined. Some see code review as a time for mentoring, coaching, showing the "better way", being pedantic and showing off reviewer skill, training less experienced staff.
What that relates to is that "crap" code turns out to be extremely subjective. Here's some examples of stuff in Java that I've seen sent back in code review for rewriting.
int x = f1();
f2(x);
The reviewer sent it back stating that it be changed to
f2(f1());
Here's another
void f3(int p1, String p2) {
float f4 = ...
The reviewer sent it back stating that it be changed to
void f3(final int p1, final String p2) {
final float f4 = ...
This are examples of what I call Programming by Proxy. We have valid, working, maintainable code being sent back for rewrite. There's nothing wrong with the code as originally written, it works properly, the reviewer just wouldn't have done it himself that way so he demanded it be rewritten to the way the reviewer would have done it. Once programming by proxy becomes the norm then code review is well on the way to the trash heap of company history as a well meaning but failed experiment.
How to keep reviews on track
The answer to this is as simple as it is obvious. Impose discipline on reviewers. Specifically this: the only thing that is actionable in a code review is runtime errors. That's it, runtime errors only. Otherwise the code stands as written.
I know some people may at first recoil at that idea. Indeed it seems counter intuitive as you are losing the value of doing code reviews. But you aren't losing value. By focusing on runtime errors only you get the most value of the code review, positive changes to the code that will correct real user affecting defects. In the 80/20 rule 80% of the benefit of code review is elimination of defects. The rest is rewriting code that works which is of marginal benefit at best.
What about the crap code though? How do we keep that out if runtime errors are the only things reviewers are allowed to raise. There's a couple of counters to that. First of all by having to submit the code to review the programmer will be more inclined to check in good code if he knows for sure someone is going to see it. The way bad code gets in is when a programmer is working by himself with no guidance or oversight and never having to answer for his work; then he can become sloppy and take shortcuts. Simply knowing that the code will be looked at will prevent most of the crap code from getting in.
Also by utilizing the 80/20 rule the reviews will finish up so much faster. That way if the reviewer saw something in the review that he personally disagrees with (like the examples above), then the reviewer is free to go in there and fix it himself.
Subscribe to:
Posts (Atom)