Blogging Ottinger (tim)

This is my second week on an intentionally, officially agile project, and I find that the planning game and various other practices are not too difficult to adjust to. The environment is not entirely familiar, but is not too bad a challenge (C#, .NET, SQL Server, Windows), though I still prefer Debian Linux for usability and maintenance reasons (and ease of software acquisition & install).

It is hard to express how much the personal productivity practices are based on verbal communication (a bit of a pain to visual learners) and on having an environment set up so that you get a “green bar” (all tests pass) as frequently as possible.

The worst part of adjusting is that there is a lot of navigation and context switching to do, more than I’m used to. I’m beginning to get it, but it’s bewildering sometimes. First you have a feature in mind, and then you have to start with an acceptance test. Not the whole test, but only enough to get a failure. To start the work that will pass the test, you have to start with a unit test, but only enough of a test to generate a failure (compile fail or execution failure). So you have feature:Test:UnitTest so far on the stack.

Now, to write the unit test, you probably will have to create some mock objects. Now it’s Feature:Test:UnitTest:Mock — then Feature:Test:UnitTest:Feature — but you only write enough of the feature to get the snippet of unit test to pass, and no more. Then you write the next unit test that brings you a little closer to passing the acceptance test along with more mock objects or more changes to the mock objects, and the code that passes the test. By this time you are running around in four or five files at the same time, and have to keep track of mock and real objects, unit tests, and acceptance tests. When you’re used to it, you can do it in your head (if my coworkers are good examples). When you’re not, it’s mighty inconvenient.

I spend so much effort in locating and navigating among files, I can forget where I am in my process — what test is at the top, where we are in the progression of unit tests, etc, what is left undone and what is yet to do.

Well, that’s not all that there is to it. After you get the unit test to pass, then it’s time to consider refactoring to eliminate duplication, so it’s Test:UnitTest(s):refactoring(s) — but of course all the refactored code has to be tested. So you may be writing tests to prove the refactoring which was written to manage duplication between two unit tests, of which at least one was a step on the path to passing an acceptance test.

When you don’t know the code base, this is triply bewildering. If you don’t understand the feature you’re implementing, it’s worse yet. If you don’t know the editor very well, it’s a bit hard to watch other people. Worse, if the development environment only lets you look at one file at a time — because you have to flip the screen between file tabs, examining the file names in the tabs to find the one you want to go to.

It gets better. It’s getting better. However, this is the one real difficult part in getting a real agile mindset, and you don’t get it without immersion. It’s asking a lot of a brain to take it all in at once.

The rest of the struggle is collateral damage, being in a lesser editor in a lesser operating system.

I really miss gvim, with multiple windows tiled horizontally and vertically, and editing without having to mouse around and use function keys. The visual studio editor is awful, but the resharper tool is sure nice. Bookmarks stink, and I’ve not learned to record and replay macros yet — something I live by in gvim. Someday I will be good at VS.Net, though I doubt that I will like it. One holds one’s nose and tries to get along.

It’s worse, of course, because the Windows system has a single desktop is not very pretty or productive. It is much more stable than it used to be, at least. Subversion is much slower than it is in Linux, too. That hurts when you use it all the time.

No wonder I’m so tired at night.