Anthony Panozzo's Blog

Title: Tribes: We Need You to Lead Us Author: Seth Godin Published: October 2008 Length: 160 pages, or 3:40 spoken

"A tribe is a group of people connected to one another, connected to a leader, and connected to an idea."

This book is self-described by Seth as a book that was supposed to be about leadership that happens to have a lot of marketing information, or a book about marketing that happens to have a lot of leadership information. The main point is that with the advent of tools to facilitate interactions between groups of people with common interests, being a leader is easier but even more important than ever. Tribes can be smaller and more precise because geographical limitations are mostly gone now. Apart from others' need for leaders, being a leader increases your happiness because you are in control of your destiny and are constantly challenging yourself. Seth makes an even bigger point: we need YOU to be a leader, and there are huge benefits to be gained from doing this. Sometimes the going can be tough, but if everyone were doing it, then it wouldn't be worth as much when someone provided true leadership. Godin emphasizes creating a movemen and working with it to allow it to thrive.

Most charity events take manual labor, so maybe you had an excuse before. But "IndyGiveCamp Charity Challenge Weekend 2009 is an initiative designed to allow developers, designers, DBAs and web enthusiasts to donate their time and talent to developing applications for charities." Hey, charities need software too!

You list your proficiencies, and are paired up with other developers (optionally of your choosing) and you work on a project for the weekend. With a schedule like this, you can be sure that you will be challenged. Heck, they say that "copious amounts of caffeine will be provided." Don't worry, you don't have to participate the whole weekend. It happens on January 23-25, 2009, which comes sooner than you'd think due to the holidays and whatnot.

Title: Getting to YES: Negotiating Agreement Without Giving In Authors: Roger Fisher, William Ury, Bruce M. Patton Published: 1991 Length: 200 pages

I highly recommend this book to anyone who has to negotiate with others. So basically – everyone. On a daily basis, you probably negotiate with your spouse, coworkers, landlords, potential employers, business owners, labor unions, and foreign governments. This book explains several principles of negotiation that are applicable to all of these relationships.

One of the concepts of lean software engineering is limiting work in progress (WIP). If you have a team of, say, ten developers, it is better to have only three or four scenarios in active development that the team is working on than having each person work on their own scenario. What's more, each developer should have only one active task at any given time. This could be a development task, reviewing a specific set of changes, or recycling review changes. This greatly helps focus the developer and ensure that context switching does not contribute to lost time and lower quality. When you are focused on one thing, you not only work faster, but you actually complete the task instead of leaving certain details for later that you might eventually forget about. Plus, it's nice to get a feeling of finishing the task.

One extremely positive effect that I saw with using this approach is that reviews become a lot easier. Let's say that I take the old approach where everyone works on a huge monolithic task and then checks things in when they feel like it. Three developers might check things in before I get my changes incorporated, and if they changed files that I was working in, the reviewer of my code might see much more than just the changes that I have made. What's more, by overloading the reviewer with the huge amount of code checked in as well as potential other changes, it's more likely that the reviewer will miss something. The review will take longer, so when it comes back to me, it might be fuzzy in my mind.

It seems like the more I read about different development models, the more I see overlap between the different paradigms. Even if you aren't using one of them for a given project, just knowing about all of them makes your code better because you realize how to make your code more testable.

One thing that has piqued my interest of late is theories in JUnit 4.4+.

Overview

In JUnit, the still experimental theory functionality is derived from the open-source Popper project. The name comes from Karl Popper's work on the philosophy of science. He was a major proponent of saying that something isn't scientific unless it is falsifiable, and that theories cannot be proven correct, merely shown to have exceptions. If someone can provide an exception, it means that the theory does not match all of our observations. Theories are models of the world, so while a model may not be correct, it can still be useful.

So what are theories in software good for? When using test-driven development, the tests serve as a form of code documentation. However, there are certain properties of code that are known or assumed by the developers that are difficult to codify as simple tests. Theories provide a simple and expressive means for at least the following cases:

• identities and data conversion
• globally disallowed behavior
• data that should be preserved after performing an operation or set of operations

For example, you might have a theory that data that is serialized into XML and then unserialized should always result in the original object. This seems to make sense, but it might be time-consuming or error-prone to specify all of the different tests that you have to consider. A single theory can codify this assumption.