Anthony Panozzo's Blog

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.

Oh man, I was so excited when I downloaded the newest version of Google Chrome in Chrome and it started automatically installing. Google is installing the update for me automatically like a real browser! I don't have to do it myself, the browser just knows that I want to update it. I messed around with Chrome a long time ago, but was put off by a lack of maturity.

Then, I got this helpful error message:

Last Friday I attended the full-day Indiana Workshops on Software Testing conference with Jen, Howard, Beth, Jeremy and about ten other people. This session was very helpful in understanding my personal knowledge of testing, learning new skills and about previously unknown technologies, and meeting people in the testing community in Indianapolis. I presented second, and discussed my experiences with Test-Driven Development on a recent Rails project that I worked on.

The first experience report probably had the most relevance to things that I have directly worked with. In the production Rails project that I worked on, we used Selenium for automated integration testing as verification of the development process. Dave Christiansen covered using Selenium to do automated integration testing on a Rails app. However, what was noteworthy to me about the approach that he took was that instead of writing and executing these tests only in the test phase of the development process, they were written and executed throughout the development lifecycle. He wrote a wrapper to generate RSpec tests from the Selenium IDE, refactored to DRY up the code, and then had the team write their own integration tests as they were developing. Since the tests were written in RSpec, they would actually be run whenever code was checked in (continuous integration.) After awhile, they built up enough helpers to stop really using Selenium at all except for replicating bugs.