2011 New Year, new things

Yes, yes, the ubiquitous New Year's Resolution post. With a slight twist: sharing my internet finds.

The first internet find, and one which I really want to encourage folks to use, is 101in365, which is developed by a former colleague, @jennjenn.  It's a way of committing to the things you want to do in the next 365 days.  Yes, you really have to think of 101 things, which really isn't that easy a task, and then lock them in and start doing them.  Its a pretty simple idea & very easy to use.  My list is here.  Some of it is mundane and some is ambitious, but none of it is unrealistic for the next year, which I think — for me at this juncture — is very good.  Some of it I've done before but that haven't done in a while (like bake a pie).  Some of it I've never done (like post a book to Blurb).  I'm very curious to see what happens in 2011 because of it and I'd love to see your lists there, too, since others can comment on your list items.  One of my items is to post at least 25 times to this blog, so here's the first post. Woo.

The second internet find is Mostly365.  It's taking the idea of a photo a day (there are many 365 groups on Flickr) and building a website around them.  The website is populated by images that are tweeted and hash tagged #mostly365, so it's pretty easy to use and it supports a number of service, including Flickr and Instagram.  At any rate, my rate of dropping out of 365 projects is pretty high, but I'm going to try to tweet a photo and that hashtag every day this year, because it's simple and I like their website. My first thought when I saw this site today was, "Wow, why didn't Flickr do this?"  Meaning, why didn't we ever leverage machine tags for site pages grouped to a theme?  Imagine an Explore >365 page, not unlike the Explore > Galleries or Explore > Analog pages.  I know. I hate the thumbnail display, too, on those pages, but it'd still be nifty.  Or gamed, probably.

I'm adjusting to moving to the next moment in my life sans Flickr, which hasn't been all that simple given how much of a power user I was of the site.  It was weird to go from being a member of a site I loved to working there… and now it's weirder to not work there but still use the site.  I don't feel comfortable engaging as much as I once did there, but that's allowed me to go out exploring on the 'net a wee bit over this holiday break.  So, other great finds I'm using daily now are Instapaper, Pinboard, and Quora.  It's so good to be a Netizen again after spending 18 months with my head jammed into the problem du jour at Flickr.  I had some fun, I had some not-fun, and now I'm having different fun.  I hope to remember to keep my online life diversified at whatever my next gig will be.

One last find, which I'm ashamed to admit I only heard of yesterday, is the concept of technical debt (or code debt).  Wow!  Really?  There is a name for this and that name is not "half implemented features"?  The concept really struck a nerve for me, probably since it's framed in terms of economics.  I'm working on getting out from under personal debt, so this rings my bell; here's the quote from Ward Cunningham that sums up the concept, 

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.

Or, as I might more simply state it, shipping a half-baked product is fine so long as you swing back around on a map to manage that code debt.  If it's not on a map, you're not taking it into consideration, and things can turn around and bite you hard in the ass if you let the debt pile-up (like my own bills).  I wish I had known that this was a concept that actually existed while at my last job, although those stories are for another day.  But I do know that if I work for someone else again, I'd like them to have this sort of debt on their radar and a plan of action to manage that debt.

Those are my internet finds for the day, the first day of this new wonderful 2011 year.
  • Mike Panchenko

    Technical debt was actually talked about amongst the engineers quite a bit, especially while Hammond was in charge. It was just never tackled in any systematic way. It’s something I’m very cautious of at my new position as well.Hope you have a better 2011 than 2010 – shouldn’t be too hard, it seems :)

  • dopiaza

    I think most, if not all, projects incur technical debt to some degree and it’s hardly ever managed in a responsible way. The combined pressures of time and budget mean it’s invariably just pushed to one side as something that doesn’t need dealing with right now. I’m as guilty as anyone else of adding to that debt, but it’s often the only way you can satisfy the conflicting requirements of required functionality vs timescale/budget. This debt is often poorly understood. When documenting systems, people invariably describe how things are done, but they tend to be less good at pointing out that some things weren’t done well. They don’t often document the ways in which the current design or implementation is deficient, highlighting the potential problems that may occur over time. Understanding the exact nature of the technical debt is a key part of being able to pay it back, but that knowledge is often not well documented and gets eroded over time. Eventually, the debt is forgotten – and then something breaks or needs rewriting – at which point things can get pretty messy. As you can probably tell, I spend a non-trivial amount of my time maintaining a couple of older systems that suffer from this kind of problem. Of course, I’m far from perfect. I too need to get better at documenting those design compromises that get made in the name of ‘meeting the deadline’ – those little ‘gotchas’ that will almost certainly get somebody one day. Perhaps that’s one for my 101in365 list…

  • ysaw

    My experience with technical devt is that its not a simple problem. Inevitably older systems get more and more difficult to maintain. At some point everything needs a rewrite. However, as features were added over time the shear about of work required to do a rewrite becomes insurmountable…some projects I worked on at Yahoo! were aimed at addressing technical debt. This generally meant a complete rewrite. During the time the rewrite was in progress it was very difficult or impossible to add new features, resulting in a stagnant product for a year.One (huge) project tried to address this problem with two teams: one working on a rewrite, another continuing work on the old product. The consequence of this of course was that the rewrite team spent a considerable amount of time porting new features over to the new codebase, because the other team kept adding them. Anyway, no conclusion, I just think that its quite difficult to keep a product solid on the internet, where users want constant improvements. (Refactors/rewrites are invisible to the users for the most part)