“I already paid for that!” he or she might say, quite correctly. A simple example recently for us here was our column picker. Our grids allow you to select which columns you wish to see on any given grid. Later on, we created the ability to have grids inside of panels on user dashboards. Our product owner wanted to put the column picker on the settings pane of a grid panel. To him, this was simply reusing the column picker that had already been created for an earlier story. He was quite shocked when our estimate for the effort was just as high as it was the first time.

His frustration is completely understandable. How is this possible? Why isn’t it easy to just drop that component into another place and have it work? After all, if we were good engineers, wouldn’t we have written that component to be reusable?

Actually, no. It’s because we were good engineers that it wasn’t written in that way. This is one of the hardest things for product owners to understand, and I hope to explain it in this post.

Evolutionary Design

Once upon a time, development teams worked in specific phases. First they would design all of the code they were going to write; boxes would be drawn on whiteboards, sequences captured in documents, and so on. Once the design was finished, the developers would go off and write the code for it. Luckily, our industry has realized that this is a problematic way to write software.

It’s simply not likely that the team will discover all of the quirks of the design during the design phase. It’s even more likely that requirements and features will change during the long span of time this process takes, forcing the developers to throw away work and go “back to the drawing board” on the design. Splitting the design phase from the coding phase is a recipe for disaster.

Instead, it’s generally preferable to practice evolutionary design; allow the design to grow organically as the code is written. This, combined with testing and refactoring, seems to be the best known way to ensure that the quality of the code remains high as a product grows.

Doing this makes it easier to deal with changes that effect design, and it prevents the team from wasting time going “back to the drawing board” in the event a problem is discovered.

YAGNI

One principle to follow as you code is the YAGNI principle. YAGNI means “You Ain’t Gonna Need It” and essentially it means that developers should discourage themselves from adding additional code to support something that is not, at the time, required. Developers have a strong desire to add code here or there while editing code, and YAGNI helps us remember to resist the urge to add superfluous code or functionality.

Following this principle helps eliminate waste, and helps keep developers focused on adding value that product owners want. But why?

If I’m editing Module A to add Functionality X, why not just add Functionality Y while I’m there? It may delay the delivering of Functionality X in the short-term, but later when it’s decided that Functionality Y must be supported as well, it will be dirt cheap, right?

The trick to understanding why YAGNI helps is realizing that there are thousands upon thousands of potential Module As in a system. The truth is, Functionality Y may simply never be required. And even if it is, Functionality Z may not be. Adding that functionality would be a waste of time and resources if it’s never used.

YAGNI Applied to Design

The same principle behind YAGNI can be extended to aspects of high-level design. When we originally designed the Column Picker component, it was not designed to be dropped into any part of the system. This was intentional: if we had spent the time to make the Column Picker completely generic and reusable, but then had never needed to drop it into another part of the system, the additional effort required to make it super-generic would have been a wasted effort. This is true for any aspect of the system being designed: we can spend the extra time and effort to make something extremely generic, but if that generality is never needed, that time is waste. Many times developers will refer to something that’s overly generic as “over-engineered.”

This means that the description of the component can often be misleading. We never built “a column picker” – we built “a column picker for a grid page”. The column picker was written in a way that assumed it was part of a grid page. Again, it could have been written more generically, but doing so would have potentially created waste (this does not mean that it’s alright to design code that violates principles of good design. Code can be well-designed but still not fully generic).

So when it came time to put the component in a completely different context than the one for which it was designed, it was still a lot of work: almost as much as was originally required to make the first pass. Though some time was saved simply because it was a known and well-understood problem for which we would leverage newly-developed knowledge, it still effectively required writing a whole new component: one that was much more generic and utilized what it could of the previous increment.

Essentially, to avoid having developers waste time, components should be “generic on demand”. Once a component needs to be reused, then it should be refactored into something extremely generic, but not before. The end result is that a product owner will have to pay for a component twice before it’s cheap.

This may seem counterintuitive to product owners, but it’s important to understand. Because the team approaches coding in a way that causes the second time to be nearly as expensive as the first, the team is able to deliver everything else quickly.

The first time, it is costly because the developers have to solve unknowns and create something new from scratch.

The second time, it is costly because it has to be molded into something generic and reusable.

The third time, however, is cheap.

It’s the result of many months of research, I hope others may find it interesting and informative.

Abstract

Test-Driven Development is a Software Engineering practice gaining increasing popularity within the software industry. Many studies have been done to determine the effectiveness of Test-Driven Development, but most of them evaluate effectiveness according to a reduction in defects. This kind of evaluation ignores one of the primary claimed benefits of Test-Driven Development: that it improves the design of code. To evaluate this claim of Test-Driven Development advocates, it is important to evaluate the effect of Test-Driven Development upon object-oriented metrics that measure the quality of the code itself. Some studies have measured code in this manner, but they generally have not worked with real-world code written in a natural, industrial setting. Thus, this work utilizes Open Source Software as a sample for evaluation, separating Open Source projects that were written using Test-Driven Development from those that were not. These projects are then evaluated according to various object-oriented metrics to determine the overall effectiveness of Test-Driven Development as a practice for improving the quality of code. This study finds that Test-Driven Development provides a substantial improvement in code quality in the categories of cohesion, coupling, and code complexity.

Download

If you’d like to read it, you can download it here:

Quantitatively Evaluating Test-Driven Development by Applying Object-Oriented Quality Metrics to Open Source Projects

Many developers think of unit tests as tests that test a single class. In fact, I myself once thought this way. If I wanted to write unit tests for a two-class system in which a class used another class, I’d write two unit tests. After all, if I created instances of both classes in my test, that wouldn’t really be a unit test, would it?

In recent years, I have revised my stance on this matter. This distinction between what is and is not a unit test is one I no longer draw in the same way.

Unit Tests need to be:

• Fast – Unit Tests should never run so slowly that they discourage developers from running them all the time.
• Focused – Unit Tests should focus on a single area so that they can isolate problems to that area when they fail.

Once upon a time, I thought ‘focused’ meant that it should be focused on a single class. Instead, it should focus on an area, but that area can include multiple classes.

An Example

Let’s say we have a simple Calculator class with some tests (normally we’d write the tests first, but since we’re talking about the tests in this post we’re going to write them afterwards). As with any example fabricated for demonstration purposes, the classes in this post have little need for the level of testing I will be applying to them, but they serve an illustrative purpose.

package com.rallydev.engblog.unittesting;

public class Calculator {

  public int calculate(char operation, int operand1, int operand2) {
    switch (operation) {
    case '+':
      return operand1 + operand2;
    case '-':
      return operand1 - operand2;
    default:
      throw new UnsupportedOperationException(String.format(
          "'%s' is not a known operation", operation));
    }
  }

}

Here is the test for this class:

package com.rallydev.engblog.unittesting;

import static org.junit.Assert.assertEquals;

import org.junit.Before;
import org.junit.Test;

public class CalculatorTest {

  private Calculator calculator;

  @Before
  public void setUp() {
    this.calculator = new Calculator();
  }

  @Test
  public void shouldAdd() {
    assertEquals(5, calculator.calculate('+', 2, 3));
  }

  @Test
  public void shouldSubtract() {
    assertEquals(1, calculator.calculate('-', 5, 4));
  }

  @Test(expected = UnsupportedOperationException.class)
  public void shouldThrowExceptionForUnknownOperation() {
    calculator.calculate('Q', 1, 2);
  }
}

But after thinking about it, we realize that the responsibility for parsing what the caller wants to do and the responsibility for actually performing that operation should be separated.

So we’re going to create a new class, CalculationProcessor, which actually handles the calculations themselves.

package com.rallydev.engblog.unittesting;

public class CalculationProcessor {
  public int add(int operand1, int operand2) {
    return operand1 + operand2;
  }

  public int subtract(int operand1, int operand2) {
    return operand1 - operand2;
  }
}

The tests for this class should be obvious, so we won’t go into them.

We will also modify our Calculator class to be injected with CalculationProcessor at construction time, which it will use to perform the operations. That looks like this:

package com.rallydev.engblog.unittesting;

public class NewCalculator {
  private CalculationProcessor calculationProcessor;

  public NewCalculator(CalculationProcessor calculationProcessor) {
    this.calculationProcessor = calculationProcessor;
  }

  public int calculate(char operation, int operand1, int operand2) {
    switch (operation) {
    case '+':
      return calculationProcessor.add(operand1, operand2);
    case '-':
      return calculationProcessor.subtract(operand1, operand2);
    default:
      throw new UnsupportedOperationException(String.format(
          "%s is not a known operation", operation));
    }
  }
}

So the question is, what should the test for NewCalculator look like?

If we follow the strict “One Unit Test, One Class” paradigm, we have to create a mock for the CalculatorProcessor and pass it into the Calculator.

One possible way it could work is by mocking out the add and subtract methods so that they have mock implementations which actually perform the operations. That solution really only works here because this example is so simple (the implementation of add is trivial). Were this problem more real-world, mocking out the responses based on the inputs may not be feasible, so let’s imagine that we cannot do this for the purposes of this post (when mocking out the responses is possible, most of this post is rendered moot, as that is usually the best way to go).

The other way to write these tests would be to create a mock and verify that our NewCalculator delegates to CalculationProcessor appropriately. It would like this:

package com.rallydev.engblog.unittesting;

import org.junit.Before;
import org.junit.Test;

import static org.mockito.Mockito.*;

public class NewCalculatorBadTest {
	private NewCalculator calculator;
	private CalculationProcessor mockCalculationProcessor;

	@Before
	public void setUp() {
		this.mockCalculationProcessor = mock(CalculationProcessor.class);
		this.calculator = new NewCalculator(mockCalculationProcessor);
	}

	@Test
	public void shouldAdd() {
		calculator.calculate('+', 2, 3);
		verify(mockCalculationProcessor).add(2,3);
	}

	@Test
	public void shouldSubtract() {
		calculator.calculate('-', 2, 3);
		verify(mockCalculationProcessor).subtract(2,3);
	}

	@Test(expected=UnsupportedOperationException.class)
	public void shouldThrowExceptionForUnknownOperation() {
		calculator.calculate('Q', 1, 2);
	}
}

I hate this test. This test does little but double-check the implementation of NewCalculator.

This test is extremely brittle. If the calculator had more responsibilities (say, multiplication, exponents, etc.) and the tests were more thorough (boundary checking, looking for division by zero, and so on) then changing the implementation of NewCalculator would require changing dozens of broken tests.

The tests are there to make us feel safe about refactoring the code, but virtually any refactoring breaks them, which requires us to manually fix the tests. When this happens, a refactoring effort loses its test harness: the code and the tests must both change together, rather than one at a time with the one verifying the correctness of the other.

Instead, I would prefer to leave the test as it was, only modifying the setUp method to correctly construct the NewCalculator with real instantiations of its dependency.

package com.rallydev.engblog.unittesting;

import org.junit.Before;
import org.junit.Test;

import static org.junit.Assert.assertEquals;

public class NewCalculatorBetterTest {
  private NewCalculator calculator;

  @Before
  public void setUp() {
    CalculationProcessor calculationProcessor = new CalculationProcessor();
    this.calculator = new NewCalculator(calculationProcessor);
  }

  @Test
  public void shouldAdd() {
    assertEquals(5, calculator.calculate('+', 2, 3));
  }

  @Test
  public void shouldSubtract() {
    assertEquals(1, calculator.calculate('-', 5, 4));
  }

  @Test(expected = UnsupportedOperationException.class)
  public void shouldThrowExceptionForUnknownOperation() {
    calculator.calculate('Q', 1, 2);
  }
}

There are a few things to notice about this test. First and foremost, the bodies of the three test methods are now identical to how they were before the refactoring. This means that the refactoring could have taken place while using the test to ensure it was correct, though the setUp method would have had to change.

Secondly, even though a real CalculationProcessor was instantiated for the test, it was not assigned to a field. It is scoped exclusively to the setUp method. This is because the test really has no reason to know about the class beyond the fact that it needs it to construct the NewCalculator.

Blurring the Line

Is this a unit test, or is it something else? Unit-testing pedants would argue that it’s not a unit test, but an integration test. Michael Feathers may disagree:

“In the industry, people often go back and forth about whether particular tests are unit tests. Is a test really a unit test if it uses another production class? I go back to the two qualities: Does the test run fast? Can it help us localize errors quickly?” (Source: Working Effectively with Legacy Code)

The test above is extremely fast, but how effectively does it help us localize errors? If it were the only failing test for a system full of classes and tests, it would help us narrow down the error pretty quickly: there is either a problem parsing the operator, or a problem performing the operation.

If we had a separate test for the CalculationProcessor itself, but it was passing, then we would know the error is in the parsing. It didn’t help us localize the problem quite as quickly as the mocking test would have, but it is also a far stronger test, less likely to break under the strain of a refactoring.

It’s a trade-off, of course, but I now tend to lean toward creating instances of the dependency classes in the setup of the test in these situations. I have simple guidelines to help me determine when I should create a mock versus a concrete instance of a class.

Verify() is a Crutch

When you’re writing a test, you go through three phases, which BDD proponents refer to as the Given, When, and Then. First you write the Givens, which attempt to fabricate a pre-existing situation for the purposes of your test. Then you write the Whens, which are the operations being tested. Last you assert some Thens, which are the expected results of performing the operation.

In the case of our simple unit test above, the Given is that a NewCalculator exists. The When is that calculate is called with some parameters. And then Then, of course, is that we get the desired result. But how do we write our Thens?

My feeling is that, if we reach into our toolbox and pull out a verify to write our Thens, we are cheating our tests out of the chance to be truly valuable. When we reach for verify, we are creating brittle tests that resist refactoring rather than enable it. We are using verify as a crutch, but we should only reach for it as a last resort.

Instead, reach for concrete instantiations of classes where possible. Create a mock that will be used to verify method invocation for one of two reasons:

1. Speed – If creating an instance of the class will significantly slow down the test, it should be mocked out instead. This is likely to be the case for classes that clearly turn tests into integration tests, such as classes that facilitate a connection to a database or over a network. This may also be the case for classes that perform a great deal of processing.
2. Complexity – Create a mock if creating an instance of a class requires creating a number of additional classes that it depends on, which in turn depend on more classes, and so on. You do not want your setUp methods to contain thousands of lines of object instantiation to support your tests. I recommend creating real objects as deeply down the dependency tree as possible, then mocking out the rest. How far down the tree should you go? That’s really a matter of taste, but I recommend trying two layers deep and no more. When you do this, you are likely to find that you have no need to verify the calls on the mock objects (other tests already cover those scenarios), but instead can set up mock objects to respond in specific ways to method invocations, simulating their behavior for the purpose of the test so that your tests can verify actual results.

Going Forward

Writing tests without the hard Unit/Class restriction allows us to write tests that enable the safe refactoring of classes, but come at the potential price of slowing down our tests and complicating the setUp methods for those tests. There is a delicate balance there, but in general I recommend trying to err on the side of concrete class instantiation in tests, at least over method invocation verification (mocking out responses is always still preferred).

This view is, of course, subject to change (as it was when I felt that the restriction was valuable), but since blurring this line my tests have remained fast and, more importantly, allowed me to code faster by letting me refactor when necessary.

Agree? Disagree? Leave a comment.

But for the last year I’ve been a very happy T-Mobile G1 user. I love the Android operating system, I love the Google integration, I love the (relative) openness of the device and the near perfect openness of the application market. I cannot imagine using a phone that doesn’t run Andoid any time soon.

Despite loving the software on the G1, I’ve never been completely crazy about the hardware itself. The screen sliding feels a little cheap to me, the phone generally feels a bit sluggish, and the trackball becomes nearly worthless after significant use. Overall, these are minor annoyances, but annoyances nonetheless. The G1 always felt like something of a knockoff iPhone; it was the thing you got when you couldn’t afford a slick, sleek iPhone from Apple. It has features like an iPhone, but generally inferior hardware.

So when I started seeing the Verizon Droid, I got excited. I was eager to switch back to Verizon (I had switched from Verizon to T-Mobile to get the G1 when it first came out) due to Verizon’s superior network coverage and the fact that my wife is a Verizon user. Moreover, the phone looked simply stunning to me. Solid, industrial, sleek, thin (or at least thinner than the G1). Overall, a bad-ass looking phone.

Unsurprisingly, I purchased a Droid the day it was released. In fact, I suffered the early termination fee with T-Mobile in order to get it.

I’ve had the phone for a day now and I wanted to offer some comparisons between it and the G1.

The Good

The hardware of the Droid is solid. It feels heavy and sturdy, sliding the screen to reveal the keyboard differs from the cheap spring of the G1 a great deal (it’s almost, but not quite, difficult to slide). The phone is extremely fast and responsive. Applications start quickly, process quickly, and generally seem speedier. The screen of the Droid is significantly larger than with the G1, and the clarity and resolution of the Droid’s screen are simply stunning. My wife’s contact picture actually looks like her.

The phone is only slightly thinner than the G1, but it makes a huge difference – it feels FAR less bulky in my pocket. The obnoxious upward curve of the bottom of the G1 is gone, replaced by a solid boxy square on the Droid. The front of the phone is devoted almost entirely to the screen. The trackball of the G1 (which becomes less and less responsive over time) has been replaced by a directional pad, and that pad can be accessed only by sliding the keyboard out, devoting even more of the phone to the screen itself.

The power button is in a more convenient place on the Droid as well. Whereas the power/lock button on the G1 was somewhat awkward to use(I always worried about dropping the phone when pressing it to darken the screen before putting it back in my pocket), the Droid’s power/lock button is easy to push and encourages holding the phone in a more solid hand configuration. The volume keys have been moved to the opposing side of the phone, but that doesn’t seem to make a difference either way.

Additionally, the vibration seems a bit stronger on the Droid. I always leave my phone in vibrate mode, but the G1 vibration was pretty weak. Often I’d get a text or a phone call and not even feel it in my pocket. So far, that hasn’t been a problem with the Droid, whose vibration is powerful without being loud. Battery life is far better with the Droid as well – a full day of use with the G1 left the battery dead if I didn’t charge it during the day at least a bit. A full day of use with the Droid doesn’t even get the battery into the yellow, and that’s with the screen significantly brighter.

One feature I particularly like is that the Droid comes with a devoted headphone jack. Listening to podcasts on the G1 was a pain, as it required using an awkwardly long adapter cable plugged into the USB port. This also prevented me from charging the device while listening to something, something I often wanted to do in the car. The Droid has a separate charging port and headphone jack, which is far easier to work with.

Most importantly, the phone connects to Verizon, so I have significantly better 3G coverage than I did with T-Mobile, especially in conference rooms at work (where I need the comfort of Google Reader the most).

The Bad

The Droid isn’t without it’s faults, unfortunately. The Droid keyboard is vastly inferior to the G1’s keyboard. Firstly, there are only 4 rows of keys on the Droid, as opposed to the G1’s five. This means pressing numbers requires using an ‘ALT’ key. Not hugely irritating, but mildly so. Far worse, however, is the fact that the keyboard keys have no gaps between them as they do on the G1, and the buttons themselves are flat rather than being slightly rounded. Typos are far, far more common with the Droid phone, it’s nearly impossible for me to get through a simple text message without fat-fingering something. To make matters worse, because the backspace key is DIRECTLY above the enter key, I find myself accidentally hitting enter when I’m trying to backspace, which means I’m sending a LOT of text messages that end in a typo, only to be followed by another text-message correcting the mistake.

Fuck you, Motorola.

Another irritation is that the Droid does not use a standard USB port. It sure looks a hell of a lot like one, but it isn’t. I could plug the G1 into anything that had a Mini-USB connector on the end. Wall chargers, car chargers, even the cables my wife uses for HER phone (very convenient if I happened to need a quick charge in her car). The Droid uses some proprietary connector, so you have to buy adapters for the thing if you want to charge it. This is completely obnoxious and unnecessary – it’s clearly Motorola trying to suck a little bit more money out of me. The real kick in the balls, however, is what the phone comes with in terms of chargers. It comes with a basic USB connector to connect it to your computer, and a wall adapter FOR THE USB CABLE. If you want to plug it into the wall, you must sacrifice the USB cable. This is particularly obnoxious for me because I had my G1’s usb cable (a standard USB with mini adapter on the end) in my office downstairs, a wall charger in the bedroom so it could charge at night, a wall charger at work so I could charge at work, and a car charger in my car if I needed to make a call but had let my battery die. The Droid’s supplied chargers give me ONE of these at any given moment, and I must separately purchase what I need for the other three.

UPDATE: A commenter has explained that the plug the Droid uses IS, in fact, an open standard, called Micro-B. A quick search on Newegg revealed many cheap Micro-B cables that I could use with the phone. So that’s much less annoying. Still would have bee nice to have a separate wall charger that didn’t use up the one USB cable that comes with the phone, though.

The camera for the Droid is 5 Megapixels. Seems impressive, except that so far I’ve had some pretty crappy luck with it. In fact, the picture of the charger took me five tries to get right, and still came out blurry, even when I switched the focus mode for closeup shots. The flash is basically worthless as well, it never seems to flash at the correct time, and it is effectively a “make this photo blurry” toggle.

Call quality on the Droid seems significantly worse as well. I have not yet determined if the speaker is the problem, but so far it’s much more difficult to hear people during a call on the Droid.

Another annoyance is how close the row of four hardware buttons are to the bottom of the screen on the Droid. I was using Twidroid and reading some private messages on my twitter account, then I hit menu. The only menu item on this screen is for “Delete all messages”. I decided I didn’t want to do that, and hit “back” to exit out of that menu. Unfortunately, the “back” button is flush with the bottom of the screen, so my attempt to go “back” registered on the touchscreen as a click on the menu item, so Twitdroid proceeded to permanently delete all of my private messages. I had to actually rip the battery out of the phone in a panic to interrupt it quickly enough, and I still lost my most recent thirty or so messages. Annoying.

Overall

Many of the nicest features of the Droid are actually features of the Android 2.0 operating system, the next version of the OS running on the G1. It remains unknown at this point if the G1 will get this version of the OS, but it’s what contains most of Droid’s coolest features, such as the turn-by-turn directions and other various improvements to Google Maps. The 2.0 upgrade also comes with a cost: a few of my favorite apps such as “reddit is fun”, “K-9 Mail”, and “Pure Calendar” don’t actually work correctly, but that will likely be fixed in due time.

I also do not yet have the Multimedia Station charger/dock for the Droid, which I think would be awesome on my bedroom nightstand, nor do I have the car mount, both of which I want and I think will make me appreciate the Droid more.

As it stands though, I’m not sure the Droid is compelling enough on its own to warrant the switch from T-Mobile to Verizon. I love the increased coverage, the devoted headphone jack, the screen improvements, and the overall feel of the phone, but I really dislike being nickel-and-dimed on chargers and I kind of really hate the keyboard (I’m hoping I get used to it).

But a few days ago, I saw the payoff: Google Reader Recommendations. Recommendation engines are one of my favorite things about the new social web – Amazon’s book recommendations and Netflix’s movie recommendations have led me to find things I never would have discovered on my own. So when I saw that Google Reader had recommendations of other blogs or RSS feeds for me, I was excited.

I figured, like most other recommendation engines, Google Reader now looked at what feeds I subscribe to and found other feeds that were subscribed to by people who subscribed to the feeds I like. This is generally how recommendation engines work: if I love “Back to the Future” and 90% of Netflix users who rate that movie highly also highly rate “Ghostbusters” highly and I’ve never seen it, Netflix will recommend Ghostbusters to me.

But when I looked at my recommendations, a strange thing caught my attention.

There is a recommendation for a blog related to TeX in there. If I scroll down, there are actually five or six other TeX resources.

This stood out because I don’t subscribe to ANY RSS feeds that related to TeX in any way, not even tangentially. So why did Google so strongly suggest them?

Well, I don’t subscribe to TeX feeds, but I am working on my Master’s thesis, and I’ve had to do a lot of Googling for help on LaTeX. A very large portion of searches I do in Google are LaTeX related, simply because I often need to troubleshoot a problem or look up how to format something.

So Google Reader’s recommendations are not merely based on feeds. They are based in my search results as well, even though that’s “separate” from Reader. It wouldn’t surprise me if people were getting recommendations based on the content of their Gmail accounts either.

Creepy.

The photos from my wedding are up on Flickr. Check ‘em out here. Our photographer was excellent. I highly recommend her.

The wedding was great. Virtually nothing went wrong – we even just barely avoided some rain but avoided it nonetheless. I was kind of dreading having to be social for a whole evening, but even the reception turned out to be a good time (though I had to go hide in order to eat my slice of cake).

Overall, being married doesn’t feel too much different from not being married. I’ve known I’d marry Julia since second week we dated, and I knew she’d make a beautiful bride (she did).

It was great seeing family and merging my 7-person family with her 100-something-person family. I also really loved how many of our friends from college were able to make it, including one of my professors. It was great seeing everyone again.

My friend Dennis was a fantastic Best Man, and Julia’s sister Olivia did an wonderful job as Maid of Honor. It was a truly unforgettable time.

I agree that there are three pillars, but I disagree about what the pillars are, at least for myself.

I’ve found that these are the main three factors in determining how happy I am at a job:

1. The People
2. The Project
3. The Company

Some of these may seem redundant, so let me elaborate.

The People

The people I work with on a daily basis matter a great deal. This doesn’t mean “everyone at the company”, it means the people who make up my immediate team. I have to find them smart, interesting, motivated, hard-working, and challenging. I need to feel like I’m improving because of them and that they are improving because of me. I need to enjoy working with my fellow engineers, testers, product owners, immediate bosses, and so forth. It’s interesting to note that I can consider this pillar satisfied if my average level of enjoyment is high enough. I can be relatively lukewarm on everyone and be satisfied, or I can even get away with completely despising one member of the team as long as I like everyone else enough to make up for it.

The Project

I’m just not interested in working on run-of-the-mill financial accounting software. It’s a personal failing, I think. But I need to find the project, the thing I work on on a daily basis, to be intellectually engaging. It should use frameworks I want to learn more about, it should regularly challenge me with requirements. The project needs to be a series of puzzles I must solve, but it cannot be frustrating due to poor project development. It needs to build easily, it needs to be easy to write tests, it needs to be checked into version control, and so forth. It should be regularly challenging without being infuriating.

The Company

This may sound redundant, as what is a company if not for people and a project? What I mean here is that I have to care about what the company is doing. I have to care about the business model, I have to feel like the company that employs me is doing something valuable for society, making the lives of users better in some way. I need to be excited by the company by hearing the overall business strategy, without meeting a single person or reading a single line of code.

The 3 Pillars

I’ve found that if I have a job that satisfies all three of these pillars, I’m extremely happy at a company. I don’t look elsewhere, I don’t consider other job opportunities. I can work there indefinitely (with one caveat, more on that in a bit).

If I have a job that satisfies two pillars, I’m reasonably satisfied. I’m not unhappy, and I can come in every day excited to do my job. But at the same time, I’m keeping an eye on various RSS feeds from indeed.com, making sure I don’t miss a potential three-pillar job.

A job that satisfies only one pillar is a job that makes me unhappy. I’m actively seeking another job and sending my resume out. I dread coming into work, and I have a hard time motivating myself.

A job that satisfies zero pillars is completely miserable. If I realized I was at a job that satisfies zero pillars, I’d quit on the spot, even without another job lined up. Life’s too short.

Deterioration

What’s interesting is that a job that satisfies three pillars can eventually turn into a job that satisfies fewer as time goes on.

It’s always possible for the company to change directions and leave me unhappy with the company, though this is somewhat rare.

It’s also possible that I can get sick of the people I work with after working with them for a long time, but this is pretty rare as well. However, if the turnaround for a company is high, it’s possible that the people I like may eventually leave the company to work elsewhere, which would cause the “People” pillar to eventually be unsatisfied unless I also enjoyed working with their replacements.

The really dangerous pillar is the second one, “The Project”. Eventually I can get so familiar with a codebase that modifying it becomes boring. The features that get added start to look alike, and I get to a point where I can work with the code on autopilot mode. A legacy project may get refactored and cleaned up to a point where there simply aren’t that many “broken” areas of the code that require my attention or offer a challenge. The work gets dull. Skorks mentions the same thing (his ‘Type of Work’ is my ‘The Project’).

Of the three, satisfaction with “The Project” is the one that is most likely to deteriorate. At a 3-pillar company, this isn’t a big deal, but at a 2-pillar company, the moment I get bored with the project I find that I’m working at a 1-pillar company, which puts me into career panic mode.

Luckily, my current job is my first-ever three-pillar company. It’s also my fourth job after college, and all three previous companies were two-pillar jobs, each one lacking a different pillar (which helped me develop the theory).

The main difference between my pillars and Skorks’s is that I don’t have a pillar for money, and I have an additional pillar for the business. I have never been unsatisfied with money, so I don’t really even think about it. I wouldn’t take a job that offered me too little to live on, and if I can live comfortably on my salary then I don’t even think about money. I wonder if that will change as I advance in my career.

The difficulty with these pillars is that, when applying to a job you know nothing about the job except “The Company”, so only one pillar is known. During the interview you have to try to size up the people and ask questions about the codebase to make a good guess about the other pillars.

Based on my differences from Skorks, I guess everyone has different pillars, but these are mine (at least, these are the ones I am currently aware of).

I got quite lucky, however, when I went through my one of these other genres, my Jonathan Coulton folder, and found a song called I’m Your Moon.

It’s a super geeky little song about Pluto and it’s moon, Charon. The chorus goes:

I’m your moon,
you’re my moon,
we go round and round.

Anyway, we both really liked this song because it was kind of nerdy and had a double meaning (to someone unaware of the science, it just sounds like a nice love song).

Unfortunately, there’s part of the song (after the second chorus) where the beat completely drops out. This makes it very difficult to dance to. Additionally, we weren’t crazy about the lyrics for this section of the song, as they were a bit too dark.

Who you were
Long before
They said you were
No more

Obviously this is about Pluto being downgraded from “Planet” status, but since a lot of the attendees weren’t going to know that the song has anything to do with planets, we decided to cut this section of the song out.

Since Coulton released this song under Creative Commons , I’ve decided to share my edited version of the song.

Enjoy!

But the simplicity comes with a price. I cannot download books from Audible.com and put them on my player to listen to them. I have to convert all of the files I download from Audible into DRM-free mp3 files. But most instructions on the internet advocate a cumbersome process, many involving that unholy beast iTunes, which effectively just plays the audio books while capturing the output stream.

I have developed an alternative to this method, which lets you convert your Audible audio book downloads to DRM-free mp3s in just a few minutes, with a very small amount of manual work.

You Will Need

• Windows (sorry, the programs needed only run in Windows)
• Nero for Windows (cost: $70, free trial available)
• UltraISO for Windows (cost: $30, free trial available)
• Ruby for Windows (free)
• Lame for Windows (free)
• An Audible.com account
• Some patience

Step 1: Download The .aa Files

On Audible.com, find the book you want and download it. Make sure that it downloads using the Audible Download Manager and results in you getting .aa files for the book. If Audible tries to make you download something else, you may have to add a new device on Audible.com. Pick something simple (not an iPod) and select ‘Format 4′ for the desired type.

Step 2: Burn to images using Nero

Once you have your .aa file (or two), open up Nero.

Create a new compilation, select ‘CD’ as the type, and scroll down to ‘Audiobook CD’

Now drag your .aa file into the Nero. Select ‘Image Recorder’ from the list of recorders. Then click Burn.

Before the ‘discs’ start burning, you’ll be asked for a name. The default, “Image’ is probably fine. Make sure you are saving into a COMPLETELY EMPTY directory.

You will be asked if you want to manually select new file names or Autocreate them. Choose auto create so you can do something else while they are ‘burning’.

The goal here is to get the .aa files, which represent multiple burnable discs, into .nrg files, one file for each ‘disc’. You’ll have to do this step once for every .aa file in your book (long books sometimes have two .aa files). This is the most manual part of the process, after this it’s smooth sailing.

Step 3: Convert to mp3

Now, you have a directory somewhere that contains files that look like Image.nrg, Image02.nrg, Image03.nrg, etc. Let’s call that directory c:\mybook for the purposes of this tutorial.

You will need to install some more software before you can proceed. Download and install UltraISO and Lame (links above). Let’s assume you have installed those to c:\program files\ultraiso\ and c:\program files\lame\, respectively. Also make sure you install Ruby.

You will also need to download this ruby script that I wrote (click ‘view source’ in the top right, copy the contents, and paste into a new file using notepad):

# Written by Rod Hilton, nomachetejuggling.com

# Modify these to be the paths to your copies of ultraiso.exe and lame.exe.
# Remember to do \\ for backslashes, and don't use /
ULTRAISO_PATH = "c:\\program files\\ultraiso\\ultraiso.exe"
LAME_PATH = "c:\\program files\\lame\\lame.exe"

# Read the directory to convert from the command line.
@workingdir = ARGV[0]
if @workingdir.nil? or not File.directory?(@workingdir)
	abort "Usage: ruby #{File.basename(__FILE__)} <path to directory>"
end

# Deletes a file
def delete(filepath)
	shortname = File.basename(filepath).slice(0..50)
	print "  Deleting #{shortname}...";
	print File.delete(filepath) ? "Done!\n" : "Failed!\n"
end

# Convert method.  Converts all files in the working directory with
# a specific extension using a function block
def convert(extension, options = {}, &function)
	Dir.foreach(@workingdir) do |file|
		if(file.match(/.#{extension}$/))
			filepath = File.join(@workingdir, file)
			command = function.call(filepath)
			print "  Converting #{file.slice(0..50)}..."
			retval = system command
			if(retval)
				print "Done!\n"
				delete(filepath) if options[:delete_after]
			else
				abort "Failed!"
			end
		end
	end
end

puts "--Converting in #{@workingdir}--"

puts "Converting all .nrg files to .wav files..."
convert("nrg", :delete_after=>true) do |filepath|
	"\"#{ULTRAISO_PATH}\" -in \"#{filepath}\" -extract \"#{@workingdir}\""
end

puts "Converting all .wav files to .mp3 files..."
convert("wav", :delete_after=>true) do |filepath|
	"\"#{LAME_PATH}\" --abr 56 -mm -S \"#{filepath}\""
end

This script basically uses UltraISO to extract .wav files from the .nrg files, then uses lame to convert the .wav files to .mp3 files.

If you installed UltraISO or Lame to different directories, change the top few lines to reflect their real paths.

Let’s assume you saved this file to “c:\nrg2mp3.rb”.

Now, open up a command prompt (Start->Run->type ‘cmd’ and hit enter). Type:

ruby c:\nrg2mp3.rb "c:\mybook"

Make sure that you use the quotes if you have spaces in your directory name.

Now just sit back and wait. The script will convert all of the nrg files to mp3 files. It will delete all of the .nrg files when it is done with them. If you’d like to tell the script not to do that, modify line 43 to remove the :delete_after stuff, like so:

convert("nrg") do |filepath|

There are lots of ways to do this, but I believe this one involves the fewest number of manual steps, and I believe it is the only method that does no analog conversion (no recording your sound card as the file plays). It is also, as far as I’m aware, the fastest method. Ripping the wavs out using UltraISO only takes a few seconds for me, and converting them to mp3 doesn’t take very long at all.

If you can think of a way to make this process faster and require fewer non-free programs (or, ideally, a way to make this work in Linux), leave a comment.

The basic cycle of modern software development looks like this:

1. The customer tells the development team (often through a product owner) what he or she wants the software to do.
2. The development team responds to this by telling the customer what it will do (via direct conversation, help documentation, the UI, etc).
3. The development team makes the software do it.
4. The customer tells the team how well it did.

It’s step 4 that generates change requests. The customer says that something isn’t working the way they want it to be working, and the cycle repeats.

Very often, you will hear developers whine about enhancements that are being filed as defects. Product owners will often respond by saying that it doesn’t matter, it all has to be fixed. A common phrase I hear is “they are all defects from the customer’s perspective.” This mentality is echoed in Practices of an Agile Developer. The attitude is generally, defects and enhancements are basically the same thing, it’s all work that needs to be done, and programmers are being pedantic when they insist on making the distinction.

But here’s the deal: the programmers are right.

I understand that it seems pedantic to distinguish between defects and enhancements. I understand that the way it looks is that developers are trying to play the “blame game.” The perception is that programmers feel that filed defects are their fault and filed enhancements are not, so when they complain about the line between the two things blurring, it seems like programmers are simply trying to prevent the company from blaming them. This has some truth to it, of course, but there is far more to making the distinction than this oversimplification implies.

The fact of the matter is, it’s important to know when the defects start piling up. If you’ve got a backlog of hundreds of defects, defects that are being filed more quickly than you can close them, your team clearly has a problem. You need to solve that problem, but you cannot do so until you’ve determined exactly what the problem is. To do this, you must know if the defects are really defects, or if they are enhancements disguised as defects.

What’s the problem?

A stack of defects means that there is a problem between steps 2 and 3. The team makes a series of promises regarding what the software will do. These promises may come in the form of public commitments, documentation, or UI that tells the user to expect certain things (sometimes subtlely). But then the team fails to make the software correctly perform those duties. Actions don’t work, menu items cause crashes, commands result in incorrect responses, data is wrong, etc. These are defects, and they indicate that the team is not going a good job making the software correctly do what it is supposed to, in terms of what the team wants it to do.

A stack of enhancements, on the other hand, means that there is a problem between steps 1 and 2. The team looks over what the customer wants and then decides what to actually make the system do. If what the system does is not what the customer really wanted, then the team has failed to adequately understand the customer’s needs, and enhancements will be filed. Functionality is needed, interfaces need to be less confusing, data needs to be easier interpret (even though it was ultimately correct). These are enhancements, and they indicate that the team is not doing a good job making the software correctly do what it is supposed to, in terms of what the customer wants it to do.

A stack of defects points to a problem in code. When the team opens the toolchest to solve the problem, the tools that will emerge are automated testing, stricter builds, better engineering practices like test-driven development or pair programming, code reviews, root cause analysis, code coverage metrics, and so forth.

A stack of enhancements points to a problem in software. When the team opens the toolchest to solve the problem, the tools that emerge are conversations, more in-depth acceptance criteria, usability testing, frequent iterations and demos, prototyping, contracting with UI designers, and so forth.

Code powers software, but it’s not the same as software. Software is what users see, code is what programmers see. If you are going to solve a problem, you’re going to need to understand where the problem is. Is it in your software, or your code? The only way to know is to draw a clear line between defects and enhancements, then look at which of those two is taking up most of the team’s time.

Does it seem overly pedantic to draw the distinction? Yes. Is it crucial to improving the quality of what gets delivered to end-users? Absolutely.

How do we know the difference?

I thought about concluding this article with some type of flow chart that asks questions to help determine if something is a defect or an enhancement. I thought about all of the different rules I use when trying to make the determination, but ultimately what I wound up with is a lot simpler than I expected.

The customer has filed a complaint about the system. The complaint states that they are expecting a certain thing to happen, but something else happens instead.

Ask yourself this: Does the something-else that’s happening violate the acceptance criteria of any user story that the team has ever implemented and had accepted?

If the answer is yes, it’s a defect. The root cause is code quality.

If the answer is no, it’s an enhancement. The root cause is software quality.

I really couldn’t think of a better way to draw a hard line between these two concepts, though I welcome visitors to comment with their own rules of thumb.