Now you're painting with Portals

-no spoilers-
You know that one level in Portal 2 where you can spray the white paint everywhere?
I did. Took me about 30 minutes. I don't know why I did that.
Then I watched my wife play. Wordlessly, I watched, and internally giggled as she did the same thing. Why?
It's like, "Oh, I missed a spot. There, that should do it. Ahh... a winter wonderland!"
At some point, we all have to ask ourselves the question, "What area do I *actually* need painted?"
But that question comes much too late, because we avoid it. We pointlessly and happily busy ourselves with the paint, pretending the question doesn't exist, or deciding just to think about it later.
That level truly is some kind of psychological test.

That blasted maven target directory

[WARN] Slightly thick maven discussion, incoming.

Sort of a holdover from when the normal procedure for checking in was to check in everything recursively in your local working copy tree, I just hate it when files that aren't controlled by my VCS/SCM get placed under that directory tree.
So I never do it. I've always made sure that the ant builds I make/use build artifacts OUTside that tree.
And along comes maven.
Come on, guys. What were you thinking?
Well, maybe they were thinking, "Hey, we all use modern IDE's which help partition our SVN checkins into changelists for us, so we don't *have* to checkin everything recursively. And also, we can easily run our status checks while excluding external directories and files we don't want to see."
Oh.
But still! Why not build the product up one directory and make the target directory a peer to your vcs-controlled one?

Well, it's configurable. You don't *have* to leave it as the default. It's part of the <build> element:


<build>
<directory>${project.basedir}/../target</directory>
</build>

But I don't like that on my CI build server, because builds of 2 different projects can clobber eachother's target directory (or leave junk in there). 

So what I really want is for this to happen only in a developer's environment. And only optionally.

There's a few ways to do this, but I chose to use the maven <profiles> in the pom, along with the <activeProfiles> in the developer's settings.xml.

In the pom:

<profiles>

  <profile>

    <id>dev_environment</id>

    <build>

      <directory>${project.basedir}/../target</directory>

    </build>

  </profile>

</profiles>

And in the settings.xml:

<activeProfiles>

  <activeProfile>dev_environment</activeProfile>

</activeProfiles>

Crappy Interview Questions

From The Oatmeal (Thanks to Daniel Spangler for the shared link)
That was so true. And hilarious.

In particular, I've personally always hated these two:

• "Why do you want to work here?" - which instantly creates a conflict of interest, and you'll find out nothing useful.
• "What's your greatest weakness?" - same reason.

Don't ask questions that create a conflict within the interviewee. Sheesh. Instead, just engage them in a dialog so you can hear how they think and communicate.
You really want to know what it's like to work with this person, so ideally, if you could arrange to work on a small problem on the board (or actually program it!) together (rather than watching them pseudo-implement your requirements), that would give you the best idea.

Engineering quote

Engineering: you're finished not when there's nothing more to add, but when there's nothing more to take away

... unless you're doing Test-driven development, of course.
That seems to have flipped that all around.

4 reasons Agile Story Points > Hours

1. Velocity
1. Normal velocity = d/t. Wouldn't make much sense to measure distance in hours. You'd get t/t.
2. You need a measurement of work (which corresponds to the measurement of distance) to divide by time and get a measurement of Work per Time.
2. Time estimates are relative (to the engineer)
1. Measurement of work is empirical. Doesn't matter who's doing it. 
2. It's a measure of the work to be done, not the time it takes to complete.
3. When estimates go bad
1. If you've been estimating Stories in hours, the response to underestimating is too often:
1. Work more hours (which increases the numerator in the t/t ratio, right?), or
2. Work faster (which decreases the denominator in the t/t ratio, right?)
2. If you're properly estimating by Story points, the response is:
1. Adjusting your estimates or
2. Adjust your velocity.
3. The net result of all this is the subtle creation of the assumption that the engineers are in fact motivated and talented to work to their capacity without strict oversight. The option to mandate more work in order to correct team product output is quietly removed.
4. Story points are the only work type that is measured in story points. Story points are also, not coincidentally, the only unit which is counted as progress toward project completion. Since, as an agile team, we agree to deliver a functional product, rather than to work a set number of hours, the amount of time we work is of no relevance. It doesn't count to project completion. But story points measure the amount of functionality added to the project.
1. My measuring stories in points, and other issues in hours, you ensure that those other issues (like bugs, or improvements) do *not* count toward project completion. 
2. This is critical in calculating your velocity. If you spend half your iteration fixing bugs introduced from the previous iteration, you will have only the remaining time to work on stories. This will reflect in your velocity, and you will therefore be correctly informed that your poor quality is affecting your forward progress.
3. By contrast, a team which writes quality code the first time (and therefore does not use up their time with bugs) will have more time to add forward progress (story points) to the project.