One of the things I miss about being on the road (other than fall arrest harnesses and my trusty Gerber) is the feeling of “doneness” you get when a show is loaded out and the trucks are padlocked. There’s no sliding scale of what it means to be finished: the show is over and loaded out. The end. You can head off to the hotel bar and kick back with your fellow road dogs and celebrate a job well done.
In software development, you never really get that sense of fait accompli. Every release of the software is an accomplishment, but it also represents a list of things you wish you could have done or could have done better. It takes a lot of stamina to write software, and even more to finish writing a software package once you’ve started. In my view, this grinding and slogging at the never-ending end of a software project is responsible for much of the burnout and high turnover you see in software development.
Whenever I sit down and look at Flex, especially when I’m working with customer data on customer issues, I often see only the flaws and all the things that still need work. If something bugs you as a Flex user, you can rest assured it bugs me ten times more. But the wishlist is long and time is short. It can seem daunting. When I become mindful of that, I try to remember something a much older and wiser software engineer once told me when I was just starting out. This conversation took place in an office building on French Broad Avenue in Asheville, North Carolina.
He told me that the last mile is always the hardest. Building new software and new features is fun. What’s not fun is correcting mistakes and ironing out the details. Good software, he said, is built by people who have the stamina to stick it out when it’s not fun anymore, when the work turns to tuning, fixing and correcting wrong assumptions that infected your design. Often this kind of work is done under duress, with time pressure, customer pressure, internal pressure. But if you have the guts to stick with it, to slog through and put in the grunt work it takes to really “finish” or come close, you’ll always come out on top, because you will have pushed past the point where most of your competitors just gave up.
I think you really see this in Flex’s warehouse process because the warehouse module has been reworked many times to incorporate edge cases and workflow exceptions comparable systems have yet to contemplate.
The last few weeks at Flex, at least for me, (Suman and Roger have been working on new labor and audit trail features respectively) have been spent down in the mire of difficult bug fixes and performance tuning. It’s been tough because estimating the time it takes to fix a problem before you understand the problem is dubious business. Performance tuning is especially tough because you have to make sure the cure isn’t worse than the disease. It’s work no one really planned on doing in the first place, it usually represents a slip in the schedule, and so this work, work that’s notoriously hard to pin down in terms of man-hours, is usually done in a hasty atmosphere under pressure. It involves long hours and often serious lapses in nutrition or personal hygiene. You often feel it’s during these times when, as a developer, that you’re most deserving of praise. But I can tell you from experience that it’s the exact time when you’re least likely to get it.
What keeps my spirits up when I have these kinds of weeks is that I know our competitors don’t have the stomach for this kind of work. But it’s this kind of work, the digging in and cleaning out the cobwebs, that ultimately separates good software from great software.