Brian On Software

This Week’s Geek Links (Feb. 29th, 2008)

February 29, 2008, 1:58 pm

This is the fifth and sixth post for "This Week’s Geek Links". I’m making up for last week due to lack of time on my part to gather relevant material…sometimes it feels good to take a break from all this computing "machinery".

Highly recommended to watch this week

"Blind Kid uses Echolocation to ‘See’"
This is one the most amazing and humbling story I’ve heard in my life. It’s about a young man, Ben Underwood, whose eyes were removed due to retinal cancer. Though blind, Ben can really "see" well and do things beyond what people with sight can do. For example, he plays video games, writes novels, is learning Japanese to study in Japan, uses Echolocation the same way we’ll use a GPS to guide our steps, etc. He’s full of life and a symbol of great courage. A must see!

Articles

"How Hard Could It Be?: Lessons I Learned in the Army"
Ex-Microsoft employee gone entrepreneur and prolific blogger, Joel Spolsky wrote an article for Inc.com in which he contrasts his experience in the army with the world of software development today. I think his article is more aimed at software development managers, team leaders or anyone in a leadership position within a software development organization; so if you’re in that kind of position, this article is for you. The main idea about Joel’s article is that, in most cases, higher positioned individuals tend to live in some "ivory tower" within the same team/organization and as a result, they tend to detach themselves from the reality of software development and to lose that special touch with their team members. Lack of respect, patience, trust and reality toward an individual or a team member is a sure road to failure in many organizations, mostly within a start-up where the strategic and corporate foundation isn’t as solid as a company like Google or Microsoft. I really liked the following piece he wrote because I think it summarizes well his point throughout this article:

Slumming may have been almost fun for you as you daydreamed about your retirement on a yacht in St. Tropez or about how you would someday regale the grandkids with stories of your salad days. But that smart programmer you hired who built your website from the ground up? Don’t you think she knows about the free gourmet meals at Google? (NASDAQ:GOOG)

I can always tell the founders who haven’t figured this out yet, because they’re disappointed in all their employees, firing good people left and right and constantly asking, "Why hasn’t Joe (or Jane) gotten this work done yet? I could have finished it in one weekend!"

"Writing Better Code — Keepin’ it Cohesive"
Software developer Matthew Cochran wrote a really good tutorial about the object-oriented principle of "Single Responsibility Principle". Instead of writing a theoretical article about it, he actually did a good job explaining the principle with a real-world example using refactoring. He walks you through all the changes he brought to an initial design and he explains the reason he chose some strategy over another all the way to the end of what he calls a "good enough design": a piece of code that is easy to read, easy to understand, easy to change and easy to test. The focus of the article is that a well-designed piece of code, i.e. higher cohesive classes, can later improve the maintenance of the design down the road. Tons of articles have been written on the subject, but just a few of them really bring the problem to the table with a realistic and simple example like Matthew’s article does. Speaking of the example, it’s nothing too fancy, just real stuff that .NET developers tend to write many times over…you just need to know a bit about .NET and the System.Data namespace to understand the example.

Blog Posts

"The Best Unit Testing Resources: Beginner to Expert"
Ben Orenstein published a good resource about unit testing, TDD, related tools and more in this post. Check out the links he provides as it might give you a better perspective on the importance of unit testing your code. Personally, I don’t care much whether you write the tests before or after the code. I prefer to write them before as it helps me to understand what I’m trying to do instead of questioning myself on how I’m going to do it. The only thing I do care is that the test is being well written and its intent is well exposed.
"The Years of Experience Myth"
Jeff Atwood shares his insight in the subject of technical recruiting. Most companies nowadays are looking for such a precise, if not perfect, candidate that has X number of years with a specific technology or has intrinsic knowledge of some tool that they actually miss out on some very good opportunities to hire individuals that are more than capable of achieving even greater things if only we would look past their current experience and see exactly what they can achieve. Human potential doesn’t rest on one’s past or current experiences but on the will of learning, achieving and improving more in many levels (personally and professionally). I’m glad my current employer had that same kind of vision when he hired me…that’s the same vision I’ll carry one of these days when it’ll be my turn to invite someone to join my team/organization. As Jeff brilliantly wrote in his post:

Somehow, they’ve forgotten that what software developers do best is learn. Employers should be looking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language — and serving them up interesting projects they can engage with.

"When TDD Goes Bad"
Yup, again on the subject of TDD. Gojko Adzic published a post on various practices to keep in mind when writing and maintaining unit tests, His post was largely influenced by one of Ian Cooper’s presentation at a user group. This is some good stuff especially if you’re looking for ways to improve your TDD techniques.
"6 Reasons To Develop Your Tests First"
I couldn’t let this one go so easily, even if it’s about TDD. This article promotes TDD by reflecting on the core benefits of the practice which the author has summarized in a list of six items to remember or to get acquainted with when starting out with TDD. Even if a lot has been written on the subject, there are still many organizations that have never heard of it and could, without a doubt, greatly benefit from adopting TDD within their software process. Here are the 6 reasons to develop your tests first, according to the author: