Austen.Ito.Blog

I was thinking about recursion earlier today so I decided to do some snooping around. Wikipedia has a nice section on recursion. Back in my college days, I learned a nifty little language called Scheme. Some of my classmates totally hated that language. They had trouble getting around the huge amounts of nested parentheses and the endless horde of recursion. Recursion here, recursion there, car, cdr, cdr, car. (Don't worry I also forgot what car and cdr mean in Scheme) In my opinion, recursion is awesome. I don't use it very often in practice, but I learned how to think about function calls by learning recursion.

I heard some one say that that Scheme is a lot like Lisp. I know that the authors of Xkcd think that it is a godly language.



After researching a bit, I did some simple recursion problems. Reversing characters, computing numbers, etc. It made me miss recursion...

I wonder what students are learning today. Has recursion been phased out?

James turned me on to a streaming music website called Pandora. Great website. Good music. Nice eye candy. If you haven't been to Pandora before, I will break it down for you. They allow you to give a thumbs up or thumbs down to currently streaming song in the genre of your choice. From there they do some "music selection magic" and select a different song that usually is something you'll like. They probably use similar ratings from other users with the same musical tastes. So far I'm really happy with Pandora. I'm hearing bands I've never heard of before that I'm starting to like. But the most interesting part of Pandora is the feeling I get when I'm logged on. It's uncanny. I feel like Pandora knows me. With music selections, it feels like it knows who I am.

With all the social networking, open social, and collective intelligence talk floating around the internet, I have been thinking that it would be cool if Hackystat would go further and try to "understand the people behind the metrics." We currently collect project data and developer data to a certain extent. From there we infer certain things like the health and direction of project or a developer's activities. What we don't do is analyze the people responsible for the direction of the project. There are many negative issues surrounding the use of developer metrics to analyze people. A big thing is that there is no way to accurately represent who a developer is with the data that is collected. There are just too many intagibles behind software development. Using developer level metrics in a scientifically proven way is hard and we have not solved that problem yet. But what if we did?

Would more people embrace Hackystat if there was a way for people to relate to the their own data? Maybe their is some type of hidden disconnect between the metrics and people. I know that I personally don't log onto Hackystat and say, "Wow this tool really reflects who I am as a developer." Is that really useful? I don't know, but wouldn't it be awesome if you could feel the same type of emotional connection just like when Pandora starts playing another awesome song (which it did just now).

Developer level metrics are interesting. I hope we can find an interesting and useful way to utilize it.

This is an additional post to Aaron's blog about a review I moderated.

Over the past couple of months, I've tried to increase my code reviewing soft skill. Early on I gathered feedback about my ability to moderate code reviews. Like any noob, I had some glaring holes in my approach. I'll try to summarize my faults so you can recognize them and hopefully avoid the mistakes I have made.

1. No offense and defense - The first couple of reviews I attended/moderated, I attacked peoples code and defended issues I found. I learned that it is very important not to think about reviews in terms of being on the offensive when pointing out issues and playing "tough defense" when explaining why issue x should be solve with that new awesome design pattern you found in Head First Design Patterns. You must be respectful of everyone's code. More often than not, they spent 100x longer deciding whether to make a certain decision. If something is weird, point it out, and ask for their input in a respectful manner.
   
   
2. Give people the benefit of the doubt - People are smart. Most times they are smarter than you. (At least it seems that way. Maybe I'm just slow...) It's silly to think that you can read someone's code for an hour and immediately know the tradeoffs of the current design. People know what they are doing and usually do things with purpose. This leads directly to my next point.
   
   
3. Stop, Shut up, and Listen - Listen carefully to what people have to say. Don't dismiss the explanations about why they chose to do something. There may be a specific reason for their choice. Again it just not productive to think that you know everything about their code.
   
   
4. Provide guidelines, not rules - So you went ahead and read Effective Java. Twice. You know the chapters by heart and know the horrors of using inheritance instead of composition. You start reviewing someone's code, and *gasp*. Inheritance. Inheritance everywhere with no composition in sight. You take out that red pen and start slashing away marking up every place that uses inheritance. During the review you cry, "Don't use inheritance or else" except the only problem is that no one is listening to you. If you want people to listen to you, provide suggestions or alternatives. You must remember that every software engineering principle and rule is not set in stone. In the end only the developer will decide what needs to be changed. If they aren't listening to you, they won't change their code.
   
   
5. Ask others for their opinion - Once again, people are smart. You will be amazed about how people think about problems. It is important to ask others what they think about the current issue. I've done this many times and have found new ways to look at code. A simple, "Is that the right way to do it?" or "How would you suggest we fix this code?" will do the trick.
   

Code reviews are great opportunity to have some fun and learn new things. Everyone is there to improve the quality of the code base and increase the team's hacking fitness. I'm planning on attending and moderating a lot more code reviews in the future. It is a learning process, but I think that I am moving forward. Hopefully I am changing out of the "know-it-all hot shot hacker that is set in stone about his methods" mold to the "nice, approachable developer that will take the time to help me without biting off my head for asking questions" type of hacker.

Software by Rob posted a link titled: 100 Resources to Attract, Retain, and Use Rockstar Programmers. One-third of the links are job boards, but below those are some interesting articles about how people in the industry choose their developers. I read two articles that caught my eye, The Engineering Value of Blogging and Hire Programmers From Open Source.

I've talked to some developers that do not see the value of blogging, but I do feel that being able to write your software thoughts, troubles, and experiences down really helps me get a clear idea of what I'm doing. You can think of blogging as doing your software design on paper. You don't just sit in front of your workstation and start whipping out code. You slow down, grab some paper, and draw out how you are going to solve problems x, y, and z. When you blog, it helps you stop and think about what has happened. You can reflect on a interesting blog you found or bring up technical problems in your current open-source project.

Both blogging and open source software are techniques to improve yourself as a developer. Well-known software bloggers often write about making yourself marketable because you never know when you will need to look for another job. Who knows what could happen. Maybe your employer is running through tough times or you just don't like what you are doing. Making yourself marketable doesn't happen overnight. It will take many years of hardwork, discipline and motivation. As a noob developer, I'm still starting on this process. It is tough staying disciplined, but I know that it will be worth it.

Give people all the information about what type of software developer you are. Help interviewers out. They are the ones that need to figure out if you are right for their company. Blogging and Open Source contributions give them that information. Type your name into Google. I know your interviewer will.

The other night I was sweeping through my feed reader as usual when I came across a blog talking about FogBugz Evidence Based Scheduler.

In evidence-based scheduling a completion date is constructed from developer estimates, but the completion date is actually a range of dates with probabilities that each date will be met. So you can look at the calendar and say “We have a 50% chance of finishing by October 31st, and a 90% chance of finishing by November 23rd.” In addition, the schedule is based on the developers’ past estimating accuracy, so the better their estimates (compared to their actual time spent), the tighter the completion timeframe. Bad estimators means a wider timeframe.

"Wow", I thought. That sounds pretty good since I am a horrible estimator. I can't give a good estimate until I get waist deep into my task. I ask Aaron about it and he shuts me down:

Austen: [Evidence Based Scheduling] is awesome.
Aaron: you think Evidence Based Scheduling is awesome?
Aaron: Write a blog on how that sucks.
Aaron: estimates probably sucks. I think software engineering research people would eat that up and show how it sucks.
Austen: I think its good. Why do u think estimates suck? is it because they are never accurate?
Aaron: First of all, it is leap. Leap sucks. It is almost like PSP. Psp sucks. Read Philip's and Ann Diseny's papers on that.

So my next task is to check out Philip and Ann Disney's Papers on PSP Data Quality. Hopefully it will help me understand why estimation "sucks."

Meticulous : marked by extreme or excessive care in the consideration or treatment of details.

I have found out this week that one of my new goals is to be meticulous. This week alone I have made three stupid mistakes that could have been avoided if I pay a little more attention to detail. Here are the stupid mistakes:

1. Totally messed up merging my subversion sensor with the main line of ant sensors. Take a look how I overwrote all of Julie's and Aaron's hard work. Philip found out that there was lots of white spaces in the build sensor. Some inspection showed that all of the ant sensors were reverted back to before my branching. Yikes.
2. After doing some work build hacking, I broke the build because I didn't test all of the modules. I tested one module, saw that it passed, and went to sleep. I wake up at 7 to find out every other module failed. Bleh.
3. Tonight, I spent an hour or so trying to figure out why SCLC would not work. With Julie's awesome help I found out that I was using ActivePerl 5.6 rather than 5.8. sigh

Being a bit more meticulous should lead to less headaches. I think this is the reason that I love unit testing. When I'm hacking I write some code, write some tests, and forget about it. I don't have to worry about my code being correct because I've tested to see if it works as I have intended. If I do find a bug, I do some debugging to figure out the cause, then write a test case to reproduce the problem. I can only image what types of horrors I would bring out if I didn't have unit testing.

Now all I need is some way to test my process.

Assert.fail("Don't be a noob you are overwriting everyone's hard work!")
Assert.fail("You didn't try every case that might cause the build to fail.")
Assert.fail("Wrong PERL version!")

Or maybe I should stop hacking at 12am...

I wonder what the Ant designers had in mind when they decided to not include the ability to have if-else logic. Tonight I started work on some Ant macros to simplify the invoking of Hackystat version 8 sensors on the current set of Hackystat 8 projects. I wanted the ability to print out a message saying, "You dont have the Hackystat 8 ant sensors installed so I'm not sending data." Seems pretty straight forward.

1. Check if the ant sensors exist.
2. If the ant sensor doesn't exist, print out a message, do not send data.
3. If the ant sensor does exist, send the data, drink some beer.

What that simple if-else logic mutates into is:

1. Write a task that checks for the antsensor jar file.
2. Write a task that invokes the sensor if the jar file exists.
3. Write a task that prints a message if the sensor doesn't exist.
4. Write a task that invokes the three previous tasks.

I spare you the 50 or so lines of ant code that I need to write just to have some simple if-else logic. I find it incredibly bogus that if-else can only be represented by setting properties and including an "if or unless" attribute in the target tasks. Not having a target embedded conditional task just makes me angry. The Ant-Contrib Ant task extension attempts to add additional features that Ant doesn't include.

Can't I just have a built in if-else clause?

On a side note, I noticed that version 7 sensor data sending code would fail the build if the sensor was not installed. Hackystat developers really should be "eating their own dog food", so it probably will be OK to require that they install their sensors.