Shih

In trying to understand the Tao of Software, it would be helpful to have some understanding of Tao. Before I can jump into that, I need to explain a fundamental concept found in The Art of War called: Shih (pronounced shir, where the i is silent.)

The Rearing Serpent sports in the mists,
The Flying Dragon rides on the clouds
But when the clouds are gone and the mists have cleared,
They are no different from earthworms.

Shih is a function of a particular configuration of circumstance. The text says that knowing shih is like being able to roll round rocks down a large hill at your enemies. Gravity, in conjunction with an abundance of rocks lets you harness the power of that configuration and be victorious. Most people can figure out that much. However, circumstances change. To stick with this analogy, suppose it rains and all your stones get stuck in the mud. They lose their effectiveness as a weapon and the shih of that particular configuration (rocks up on a hill) is no longer available to you. Instead, you need to look to harness the power of the new configuration, like damming up some of the newly formed rivers so you can unleash a torrent of water as your enemies approach.

In modern day terms, we are less susceptible to changes in the weather but perhaps we can see a parallel in rapidly changing market conditions. A new regulation is passed, a well financed competitor moves into your space, the talent pool dries up or key people leave the company. To go on doing busines the way you've always done, is certain death.

As an software professional, we no longer have the "luxury" of being able to plan out our products 3 years in advance. The market moves too quickly and when push comes to shove, customers don't typically know what they want until they see something similar. As such, we can never afford to set any plans in stone. The best we can do is build something that's close to the specification and then return back to the customer to find out what they really wanted. In software, the forms we deal with are not rocks and mountains but classes and functional dependencies. As the requirements change, we need to be able to affect those changes on an existing system with as few modifications as possible. A well factored web site will allow you make adjustments to a single CSS to alter the entire look and feel of the site.

We pursue an agile development methodology because we understand that changing market dynamics (shifting shih) will alter how our customers will use our products. Harnessing that new configuration will give us a greater ability to compete in the market. Ignoring it will lead to our demise.

Another piece of the puzzle

There comes a point in a young company's life where the white board is no longer the best place to store your bug reports. This is especially the case for the "wait, didn't we fix that last week?" variety of bugs.

I'm all about kicking things out the door quickly and getting user feedback but if the thing keeps breaking, people are going to quit using it. I've had limited success with bug tracking systems in the past as they can rapidly become very cumbersome and before you know it, nobody's using them.

Recently, we've starting using FogBugz (http://www.fogcreek.com/FogBugz) and while I wasn't surprised to see how many defects we had, I was surprised at how everyone has responded to them. Suddenly, quality isn't just my concern. Everybody seems to have turned their attention to testing and fixing defects. Granted, there's been some overhead added to my day as I try to teach the team to write better bug reports (so that developers can actually reproduce them) but it's well worth the effort.

A big thank you to the folks at Fog Creek for making such an excellent product that everyone is happy to use.

iTunes + iPod = lots of swearing

I guess it's more iTunes I'm having trouble with but I've only been cursing Apple since I bought an iPod.

We're told that they're so easy to use. What we're not told is just how finicky iTunes is and how happily it will erase whatever was previously on your iPod at the drop of a hat. For any person fortunate enough to have not bought one yet, learn from my mistakes.

Setup:
Most of my music (~14 of 16 gigs) is on an external drive since I don't have a lot of confidence in laptop hard drives.

I noticed that every time I plugged in my iPod, my computer would be pegged for about an hour and a half. Finally, I realized that unless you override the default setting and say that you'd like to manage your own collections, it will completely overwrite EVERYTHING on your iPod every time you make the mistake of plugging it in. Thanks Apple. I figured out that little problem and was briefly happy with everything working fine. Little did I realize that this was just the calm before the storm.

Problem

If you ever fire up iTunes and forget to connect your drive, you're basically screwed. As quick as a wink, it will zip through all your music and mark it as missing. Ok, fine. Plug your external drive in and... those songs are still missing?!? If you double click on them, iTunes cleverly realizes that it's made an error and it does actually exist. There doesn't seem to be any automated way to get them all back unless you click on each missing song. Given that I've got ~4000 songs in my collection, that could take a while. Grrrr.

Solution 1

I had noticed in the past that if I re-imported directories that I'd updated with new music, iTunes was actually smart enough to only import songs it didn't already know about. Perhaps, it's smart enough to find my missing files if I re-import my directories.

Nope.

Now I've just doubled the size of my supposed playlist, even though it can only find 1/2 the songs.

Solution 1b

Ok, so iTunes has this fun little feature where you can delete duplicate songs. Can I just delete the ones iTunes can't find? Don't kid yourself. I have the option of going through and selecting every other song in my freaking playlist and then deleting them (single clicking 4000 songs is slightly less painful than double clicking 4000 songs... after all, I'm saving about 4000 clicks...)
which almost seems palatable until I realized that playlists are associated with the MISSING versions of the exact same files I just imported. WTF??? Aren't they the same files? They live in the same place! *groan*

Solution 2

Hey, maybe I'll just delete everything and re-add them. Ok, that kinda worked except for my exceptionally short memory. I've got all my songs back but now all my playlists are empty. No problem, I'll just plug in my iPod and manually copy over all the songs in my playlist there (recall that I've set iTunes to manually sync with my iPod.) I happily plug in my iPod and ... hey! Why is it updating? I didn't tell it to do anything yet! Make it stop!!!!

Apparently, that setting was designed to lure me into a false sense of security. Now all my playlists on my iTunes and my iPod are empty.

Fuck you, Apple.

Daily Scrum

One of the principals of scrum is that every sprint delivers something of business value. More often then not, there is a lot of other work that went on in the sprint that cannot be shown because it's not complete. There's a lot of value in letting your stakeholders see what you have got working.

1. The stakeholder benefits from seeing progress in terms of something that actually works.
2. The developer(s) benefit from early and frequent feedback on how well the thing they're building is going to meet the customers needs and can then adjust their course accordingly.
   

I've started a new job recently and I've decided to apply this concept on a daily level. Upon joining any new organization, there are a lot of things to learn. As a knowledge worker, your colleagues are also trying to learn about you. You got through the interview so they know they'd like to work with you but it's difficult to discover a person's strengths and weaknesses until you've had a chance to work with them for a while. As such, I've taken on a small research project that I can focus on in between the huge knowledge dumps. This gives me the opportunity to study some aspect of my new industry in depth and give back some business intelligence to the organization in the process.

Being able to contribute some small thing each day gives me an opportunity to start collaborating with my new teammates and build professional relationships with them. The wizards of scrum will tell you that it scales up well. Apparently, it also scales down with good results.

Ping pong sandbox usage

Interesting article by Mike Spille.

While I haven't noticed us doing this in our code, it does make me think of our sandbox practices. (I say practices because although our strategy hasn't changed, we tend to vacillate in our observation of this strategy...)

When I joined the company I'm now with last October, there was a big push to "always work in sandboxes". That is, do all development work in a private branch. Once that code is stable, integrate it in to the project branch. A month or two after we adopted this as our official policy, I noticed that most people on my project team seemed to be working out of the same developers' sandbox - let's call him Dave. Eventually, people concluded that occasionally breaking the build was slowing things down for other developers and started making sandboxes off of Dave's sandbox (so they stayed in sync.) This made things extremely difficult for anyone who wasn't in a Dave-sandbox-derivative to keep their sandbox in sync and put tremendous pressure on Dave to continually sync to the project main so they could sync their Dave derivative sandboxes with anyone who was correctly following the practice... In short, it was a mess. Slowly but surely, people moved into their own sandboxes (off the project branch) and then started doing feature sandboxes for collaboration and all was briefly well.

Enter Scrum, stage left. We now have a new and exciting agile development style that is going to help us build software faster. To keep the three sprint teams from colliding, we made a branch for each team, and gave each Scrumaster the responsibility to keep those branches in sync. This was cool but then all the developers started doing all their work in their team branch. Again, we started running into the problem of risky code breaking builds and hindering the development efforts of our teammates. My team went back to strictly working on sandboxes. Today, after a lot of head scratching and emails as to why a particular bit of code didn't seem to jive with what I was expecting, I realized that I needed to perform my 5th integration to get the updated code, making me wonder if this sandbox thing was too heavy weight when a simple check in/out and sync would have been less cumbersome (assuming we were in the same branch!)

I'd like to propose some middle ground on this sandbox thing:

"Try to work in sandboxes for code that might put you in build hell. Share the team branch for highly collaborative but relatively low risk code. Use your judgment on anything in between."

jk

It seems to be the norm to write up a little introductory post when creating a new blog. As a software devleoper who takes his career pretty seriously, I spend a lot of time thinking about how to do it better. In order to do this, we need to use some kind standard definition of "better".

I define getting better at software development as:

Producing working software that meets the customer's needs, faster.

I don't want to be a code monkey who just spits out code fast to meet some business need. I want the code to function correctly. I want it to be maintainable so when I move on to my next assignment, the person coming after me can understand what I was doing and modify it without swearing at me or rewriting the thing from scratch. I want it to contain the minimum amount of code to get my feature to work while providing maximum extensibility to some who'd like it to do more. And since I get paid to write code, I only want to deliver code that delivers business value, whether internally or externally.

This blog is intended to document my quest to deliver relevant, working software quickly.