So just about a week after my first ever semi-professional photo shoot, I got to do it again, this time at the Blue Talon Bistro. What fun!

We actually did it over two nights this time since Chef was not at the restaurant on Monday (yes, everyone just refers to the chef as Chef). After we did the shots of the dining room on monday, the kitchen treated us to a full dinner which was quite amazing (including wine). Food just kept coming out to eat; I was quite stuffed and was slow to want to move around even the next morning. This is what makes doing restaurant shoots worth it. Tiffany and I spent the whole time chatting it up with the bartender, who is an up and coming graphics designer.

On tuesday , we worked in the kitchen. The Talon’s kitchen is much more of a “working” kitchen as opposed to the Fat Canary’s “show” kitchen. They both get the job done, but the Talon’s does not have a lot of extra room to stand in and the lines of sight are not there, making this much more challenging. But the light was much better and that made taking the shots easier.

I was amazed at the difference in the attitudes between the two restaurants. I realized that a chef, like that at the Fat Canary, who is comfortable having a kitchen that is wide open to the dining room clearly has a more outgoing and gregarious attitude. This attitude carries over to his staff and the feeling in his kitchen. The Talon has a more traditional kitchen, and while everyone was very nice, they were also much more serious and interested in getting work done. You can even get a taste of the difference with the servers and others outside the kitchen.

So much fun; I hope I can get to do this more.

Blue Talon Shoot Gallery

Good morning everyone. I thought I would share a technology solution to a problem I have been facing with calendars. Up until a year or so ago, I was generally anti-calendar. This was not really a technology problem, it was a bandwidth control one; it was my belief that if I had so many things going on that I couldn’t keep them in my head, it was too many. This was probably foolish, but it worked for many years. My life tended to be “event driven” so many things I didn’t have to plan towards. But as I have moved on, expanded my social circle, expanded my work activities, and frankly, gotten older and slower, this method didn’t work so well. As an example, here is a week from my work calendar:

So keeping it in my head is not going to happen.

Here is the landscape I am trying to manage as it stands now:

• Calendars I pay attention to:

  1.  My personal calendar 2.  My work calendar 3.  My travel schedule (provided by the awesome [TripIt](http://www.tripit.com), highly recommended) 4.  Shared calendars for Tiffany and others
  

• Devices I use:

  1.  Personal computer at home 2.  Personal laptop 3.  Work laptop 4.  Personal iPhone 5.  Work Blackberry 6.  Other internet enabled computer
  

• Another item of note. I don’t want to use something web-based all of the time. I like desktop applications (iCal by choice, Outlook by necessity at work), so supporting those is critical.

I initially solved the problem of dealing with calendar 1 and devices 1, 2, and 4 by using Apple’s MobileMe. This worked very well for syncing those devices but it fell down in trying to sync external calendars (like 3 and 4) or getting it to other devices. (I still use MobileMe for keeping bookmarks and contacts in sync, for which it is great.) It also had no way of getting my work calendar in place.

As is unsurprising, I finally settled on switching over to Google Calendar as the central repository for all my calendars. It has worked very well, with only one hack to get a limitation of Google’s Outlook sync to work right, but more on that later. So here is my solution:

• A central Google Calendar account. It contains:

  *   My personal calendar as primary *   Subscription to my TripIt calendar *   Subscription to friend's calendars *   Subscription to secondary Google account for work (see hack below)
  

• Google Sync for my iPhone with visibility to any of the calendars above.
• A secondary Google Calendar account to sync for work using Google Calendar Sync. I had to create a secondary Google calendar account for this because the current version of the Google Calendar Sync only syncs Outlook with a primary google calendar, which is my personal calendar. I didn’t want to mix my personal calendar items with my work ones. By having Outlook sync with the secondary Google account, I can keep them separate. Additionally, I only view work events through Google, so the extra hop was not a problem.
• Google supports CalDAV integration with iCal. This allows me to see and edit all of my Google calendars through iCal.
• Outlook can get a read-only copy of my personal calendar via a private feed allowing me to view it in Outlook.

Phew. Make sense? It isn’t really as complicated as it sounds, I promise. With the exception of the hack to get Outlook data up into the system, my primary Google Calendar account sits at the center and everything else syncs with it.

So, this solution works for me. I am currently investigating how to maintain to-do lists through the system. Google has them, but I don’t yet know how they will sync across the system. Also looking at Remember the Milk which also integrates with Google Calendars.

I hope this information is useful helping someone else set up a central system without all the fuss I went through to get here.

It has been a bit since I posted. I keep having ideas of things to post, but just never get the energy up to do so. My friend Michael has started posting again on his blog, Madking’s Musings, about all kinds of techie stuff. I love reading the entries and often want to make a response, but haven’t yet done so. Nor will this post correct the lack.

Nope, today is just a quick note about a great thing I did this past Sunday. After a great mother’s day weekend with Tiffany’s family (and yes, I called my mom too), I got invited to help with a photo-shoot for The Fat Canary in Williamsburg. I have never really done an “official” photo-shoot before, so this was new. We had a list of types of shots we wanted and the “feel” we were going for. The idea being to capture the neighborly, friendly aspect of the restaurant, which I can attest to as it is one of my favorites in town.

We spent over an hour trying not to get run over by the wait staff and trying not to annoy them too much as we took their pictures doing their work. The kitchen staff seemed to enjoy the attention (for the most part) and was very chatty while we watched them work. The general darkness of the inside gave me a new appreciation for my el-cheapo 50mm prime lens and makes we want to look at getting one of the slightly better ones.

I think what I enjoyed most is that given the event was a “sanctioned” one I did not feel awkward taking pictures of people. It is something I feel generally uncomfortable with while I am in public or just hanging around with friends. But in this instance, it really worked and I am proud of the shots I got. I think I was able to really capture the emotions of the people working at the restaurant.

I’m looking forward to doing more of these in the future.

Fat Canary Shoot Gallery

For many years, there has been a trend in all industries to look to outsourcing as a method to “reduce costs” and “improve efficiencies.” In the software industry, this has given rise to large numbers of firms in countries where the cost of labor is low; India, Eastern block countries, Malaysia, etc. This is a popular topic in management and business books. But does it really work? Does it let a company produce better software for less? I think not. And I think it fails on several fronts.

Team building - Producing quality software requires a strong team. What makes a strong team? The question that is usually asked, is whether a team has “jelled.” To me this means are they all thinking on the same wavelength. Does the team communicate outside of the traditional methods of email, specifications, designs, memos, meetings. Do they get together for a beer or dinner after work to socialize, but end up hashing out that tricky algorithm? The thing you may see here is that all of this requires physical proximity. It is very hard to create this jelled team when you are in 4 time zones spread across the globe. As an example, I had a conference cal yesterday with all of the software managers in Swisslog; in order to make it work, I had to wake up at 5am and the guys in Australia were up at 10pm.

“But wait!” you say, “what about all of those open source projects that have people all over the globe? They can do it! Why can’t you?” Simply put, they are different. If you look at most open source projects, you will find while a large number of people may have contributed, there are usually a very small group of core contributers who do most of the work. They receive patches and suggestions from the group but do the critical work themselves. The other huge difference is that open source projects don’t have to be cost effective, everyone is working for free.

Costs - Cost is the bean counter argument for outsourcing. Why pay $120/hour for a programmer in the US when you can get 4 programmers in India for $30/hour? On the surface it seems like you an get far more work done for less money. But in reality can you? I don’t think so. From my experiences, you end up spending far more money with offshoring. The cost of the off-shored programmers is cheaper, but you end up spending more money on on-shore activities. In order to have a successful offshore, you need rock solid requirements, specifications, and designs. You also need far stronger project management. This all takes time.

Communication - So now you have a bunch of code from your offshore team, now what? You need to test it, which will inevitably find bugs. If you are in the US and working with a team in India, you generally communicate via email. I have heard the argument that since they are nearly 12 hours off that they can be productive while you sleep. That sounds good, but in reality what it means is that every email “transaction” now takes 24 hours to complete.

Obviously I am not a fan of this method of development. Can it work? I’m sure it is possible for large projects where the entire project takes place in another country, but then you are not really offshoring, you are just onshoring it in another country. I have seen multiple companies I have worked at try to make this work, and I don’t believe it can in the small/medium sized tech companies.

What do you think, am I right?

If you want to progress and grow in your career, you have to confront new challenges. When I started as a developer, the challenges were straightforward; write code at the direction of my technical lead. The scope of my decision making power was small. I could choose how to implement an algorithm, but the larger decisions were out of my hands.

As I grew, I wanted to make more of a difference in the bigger picture, but still at the technical level. I moved up to the role of technical lead. The biggest challenge was no longer the technical, it started to be people. What did the customer want? Not what did they say, but what did they need. Learning that people are not computers was hard. I couldn’t assume that my audience would understand what I understood. I had to learn people. And people are messy, illogical, emotional, greedy, and unpredictable, the antithesis of computers. It took time, but I got good at it.

This brings me to today. As a manager of technical staff, I mostly deal with people. While understanding the technology is important, understanding the problem is more important, and most important is knowing who to apply to the problems to achieve the best results. This has its easy side when you are acting in the positive direction; applying the right person to the right task. The much harder part is when you make a mistake and have the wrong person in a role. You have to be willing to make a switch. I may know it is the right thing to do, but it is hard. Seeing what is best overall may not be percieved to be best by all the individuals involved.

These challenges have forced me to grow in my job and as a person. I do hope I am making the right choices. I’ve had great teachers so I feel confident. I think if I ever stop worrying it is time to quit.

So much for my musings at 38,000 feet.

I have a favorite question to ask people on interviews for software development: “Do you see programming as an art or a science?” There is no “right” answer to the question, I want to see how they answer it. For me the answer is both. While technical competency is critical, the mark of a truly talented software developer, or more accurately, designer is a creative spirit. While a nice lead in, my interview question only partly relates to what I thought I’d write about. The last few days of crappy weather have put me in a thoughtful mood, one where I found myself settling on the topic of creativity and what makes people (or more importantly, me) happy.

Looking at software again, the aspect of development that kept me up at night, brain turning, writing notes, forcing me to go into the office early was the challenge of solving the problem. Let someone else do the execution, that is the gear turning part, the true joy comes in figuring out how to make the machine. And I’m really good at designing the software machine. The challenge and sometimes frustration comes when I have the passion but not the skill (yet) to execute what I can see in my head.

My photography is definitely at that stage. I love photography but haven’t reached the point where I can always capture what I see in my mind’s eye. I am very proud of what I have produced, have filled my house with great art that I created, and enjoy looking and having it looked at. However, it doesn’t feel like I have “got it” yet. There is something that seems just out of reach, as if it were right there that if I could just get my hands on it, everything would click. When Tiffany and I saw an exhibit of Ansel Adams it is blindingly obvious that he had that thing. Whatever that thing is.

It makes me think of when I was a kid. My father was a very talented artist; painting, drawing, doodles all over the place. It was as if his mind could not function if he didn’t keep that part of his brain busy. It is an an aspect I did not think I had inherited but maybe I have, just in different mediums.

It is cool that the desire to create seems independent of the tools. For me it can be capturing a beautiful image, creating a wonderful meal, writing an elegant email on a meaningless topic, developing a cool solution to a computer problem, building a simple, clean website, or even just a nice turn of phrase. The urge to create is a great thing and it is amazing how satisfying it is.

The internet is big. And it has lots of cool stuff. Too much at times.

For the longest time, when I found a site I found interesting, that I might use again, that I wanted to read on a regular basis, I bookmarked it. Plain and simple. Functionality that has been around since NCSA Mosaic (yes, I used that on the old AIX birds systems at W&M). Bookmarks scale moderately, but not past a certain point. I certainly crossed that line when I had over 1000 of them.

The first change I made several years ago centered around sites that I wanted to read regularly. With the advent of RSS feeds and the centralized service provided by Newsgator, I moved all of the blog and news sites I read out of my browser and into my RSS readers (NetNewsWire for Mac and iPhone and FeedDemon for Windows). This system works wonderfully. I get notified when I have new articles to read, they are shared across all my computing devices, and the software is well written and intuitive.

But it wasn’t enough.

I still had over a 1000 bookmarks. In looking at them, I saw that they fell into two categories:

• Websites I need to access on a regular basis (i.e. banks, reference sites, etc)
• Websites I don’t want to forget or ones I think may be useful “later”

The first group of sites are perfect for bookmarks. Their number scales linearly with my life and seems to be relatively bound. There are only so many websites I will visit on a regular basis, just as there are a limited number of stores I will visit regularly in real life.

The second group is more of an extended history function. Like that restaurant that I went to 6 years ago in New Orleans that I want to remember if anyone says they are visiting the city or I go there again at some point. Hardly a regular piece of information, but I don’t want to forget. Of the 1000 plus websites I had bookmarked, probably 95% of them fell into this category. They completely obliterated the 5% I needed to use regularly no matter how well I organized the structure.

I needed a new solution.

I have settled on using Delicious to keep track of those “might be useful later” websites. It will allow me to be a digital packrat when it comes to websites, but keep the clutter out of my day to day operations. I hope the tagging and searching features will allow me to retrieve that stored knowledge in the future; only time will tell. I have imported all of those 1000 bookmarks into the site and will in the next day or two purge them from my browser. I can’t wait.

If you are curious, nosy, or just bored, you can browse through all of them on my Delicious page here. Enjoy.

So, it is kinda a big day. It seems right and proper that our first black president is being inaugurated the day after Martin Luther King Jr. day. As I was driving to the airport in Richmond this morning the VDOT highway signs south of Richmond were advising people driving to the inauguration to call 511 for traffic information. Note this is over 100 miles to DC. So yeh, I think it will be a big day.

I have high hopes for the Obama administration. Moreso than the obvious milestone for race relations in the US, I see his election to be a generational shift. Having a young president with a better understanding of where the country might go in the future. I think that is more important to me I hope he does well and can live up to some of the hype surrounding him. However the blind faith I heard on the radio on my drive gives me pause; people declaring categorically that he will be the best president ever. I certainly hope so, but none of us know. He may be a Kennedy or an FDR, but sadly he could be a Harding. Only time will tell.

I know however that I look forward to finding out.

I mentioned in my last post that I spend time thinking how I would run a software group if I could start from scratch. I won’t touch on how one retrofits this into an existing organization with institutional inertia (see previous entry on monkies and firehoses). I wanted today to talk about the tools I think are critical to a team.

[Note: I wrote this orginally at 30,000ft on my way to Jaxonville, FL so there are no links to the products below. I will try to come back and add them later. Updated 12/12/2008 with links]

Source Control

This is non-negotiable. Whether you use a commercial tool like Perforce or open source tools like Subversion, you must have this. It needs to be the right hand of all developers, ingrained into their daily habits. All code must be checked in at every opportunity. If working in a shared codebase, one must be careful to not “break the build” but developers should plan their work so that it can be done at least once a day if not more often. This takes discipline but if the habbits are developed from the start, it will pay off in the end.

Online bug/issue tracking

Tools like Bugzilla allow a team to keep track of problems and tasks pending while giving project managers and senior management a view into the project that can be tracked over time. But in order to be used, the system needs to be simple and straightward to use. The instant it becomes burdensome or even annoying to use, it will become neglected and not used. This applies to data entry, searching, and reporting.

Wiki for documentation

This probably the most controversial. It is my believe that using tools like Microsoft Word are horrible tools for collaborative document writing; exactly the thing you need for the creation of the most important documents in a software project; requirements documents, functional specifications, technical design documents, test plans, and more. Word docs get emailed around, changed by different people at different times with little tracking in place. More time is spent in document management than in actual content creation.

How does a Wiki solve this? You get a central document that anyone can access and edit without emailing them around and having to reconcile changes. It provides change control and tracking so you can see who makes what changes. It also has the built in capability to link between documents to show the relationship between a design section, it’s corresponding functional description, and the requirement it is supposed to fulfil. Many wikis also have the facility to host discussion forums tied to a document but seperate from the content itself. There are obvious challenges of freezing the document at key points in time I believe this is small in comparison to the benefits.

I have never been able to implement this particular idea but I am convinced it will make everyone more efficient.

(And, yes, a wiki can be used for so much more and it should, but that rarely takes as much convincing.)

While I don’t have a huge readership here, I know most of them are software people, so what do you think? Anyone have a great idea and the money to let me give it a go?

2 Posts in 2 days, wow. But it is largely just a big cut and paste, so I guess I don’t get too much credit.

There’s an old joke, so old that I don’t even know for certain where it originated, that’s often used to explain why big corporations do things the way they do. It involves some monkeys, a cage, a banana and a fire hose. You build a nice big room-sized cage, and in one end of it you put five monkeys. In the other end you put the banana. Then you stand by with the fire hose. Sooner or later one of the monkeys is going to go after the banana, and when it does you turn on the fire hose and spray the other monkeys with it. Replace the banana if needed, then repeat the process. Monkeys are pretty smart, so they’ll figure this out pretty quickly: “If anybody goes for the banana, the rest of us get the hose.” Soon they’ll attack any member of their group who tries to go to the banana. Once this happens, you take one monkey out of the cage and bring in a new one. The new monkey will come in, try to make friends, then probably go for the banana. And the other monkeys, knowing what this means, will attack him to stop you from using the hose on them. Eventually the new monkey will get the message, and will even start joining in on the attack if somebody else goes for the banana. Once this happens, take another of the original monkeys out of the cage and bring in another new monkey. After repeating this a few times, there will come a moment when none of the monkeys in the cage have ever been sprayed by the fire hose; in fact, they’ll never even have seen the hose. But they’ll attack any monkey who goes to get the banana. If the monkeys could speak English, and if you could ask them why they attack anyone who goes for the banana, their answer would almost certainly be: “Well, I don’t really know, but that’s how we’ve always done things around here.” This is a startlingly good analogy for the way lots of corporations do things; once a particular process is entrenched (and especially after a couple rounds of employee turnover), there’s nobody left who remembers why the company does things this way. There’s nobody who stops to think about whether this is still a good way to do things, or whether it was even a good idea way back at the beginning. The process continues through nothing more than inertia, and anyone who suggests a change is likely to end up viciously attacked by monkeys. But this is also a really good analogy for the way a lot of software works: a function or a class or a library was written, once upon a time, and maybe at the time it was a good idea. Maybe now it’s not such a good idea, and actually causes more problems than it solves, but hey, that’s the way we’ve always done things around here, and who are you to suggest a change? Should I go get the fire hose?

This is taken from an article Let’s talk about Python 3.0 by James Bennett. I hope he won’t mind I have reposted it.

Why did I post this as a whole? Because it is so true. It is a human behavior I have known and not understood throughout my life in software. For a long time, I was just frustrated without knowing why. The realization that I was different, that I did not have as strong a shackle on the past was a blessing when it came. Not that I was any less frustrated when I saw the practice in life, but I knew why. It allowed me to focus my efforts and help people understand that just because we “always did it that way” did not make it a good idea.

Being the person to play that role is hard. People do not like hearing it. And sadly, getting attacked by the monkeys is not fun at all. It wears on you when you do not see a way to convince people. You bring them numbers, show them the tole their policies are taking in terms of dollars, in terms of people, in terms of families, and they can’t understand that there could be a better way if they only let go of the past.

But it is in me to be that person, and I love doing it. I have plans and I’m stubborn and I can’t wait for the opportunities to do the right thing and see the results.