I just did some research on PicFog for my new tumbleblog when it occured to me it’s not nice that you can’t navigate with the usual J (down) and K (up) keyboard commands.

So now you can! 

A couple of months ago I started to rewrite the site from scratch. The intention was to start from something -really- simple, add the currently existing features one-by-one, and when PicFog 2 is ready, just replace the old site with the new. So, naively, I started with a nice little {}, and got on with refactoring everything I could put my hands on.

And then reality kicked in: with the limited amount of time I have on my hands (one day a week, plus whatever I can steal from weekends), I have to be really prudent with my time. If I have to finish the following by the end of the day:

1. bug to fix,
2. a feature to polish
3. do some refactoring,

I have to look at what’s the best value I can deliver. And refactoring may feel good (I’m a developer after all), but the other two actually ship something. So when my charts showed I’m not shipping enough, I changed tactics: took a look at the half-refactored code, and took the new stuff and chucked into the current one, roughly one a week.

The last feature I pulled in to PicFog was infinite scroll - it’s very smooth, both the code and the actual feature (much better than the previous incarnation), give it a try! Have a look at the E3 pictures - you really need a nice smooth scrolling there.

…

So here is Janos’s lean refactoring guide in three simple steps:

1. Start doing some code refactoring.
2. Get real: Identify the usable organs in your half ready code.
3. Put the organs to your live code. Don’t think a lot, you already have.

And: profit!

Did this tactic produce good code?

Probably not as good as The Perfect Refactor, but I still managed to improve the quality of my code (not that anyone cares, ha!), and actually got rid of some annoying nuances.

Is this the ideal way of doing it?

If you have infinite amount of development resources, probably not. If you write The perfect code on your first try, probably not. But if you’re lean by design (and I’m very lean, trust me), you might want to follow the three magic steps. And careful: all three steps are equally important. You have to do some refactoring (at least in head, ha), then have to identify what can you use, then have to relatively mindlessly do the organ transplant thing. 

Is lean refactoring the ultimate tactic?

For certain things, it worked suprisingly well for me.

Back end / database code: perfect.

Code that doesn’t fundamentally change the interface, just improves it: good.

Minor interface changes, be careful.

Interface design: I think it’s the perfect way to kill a design is to replace different features one by one, making the experience confusing and inconsistent. You might want to approach this one differently. But hey, I’m just a developer, I don’t do design.

A selection of PicFog mentions from the last month. I’ll try to make this section regular.

• PicFog was mentioned in the Swiss radio station DRS 3 in the programme called ‘DRS 3 Digital’. Listen to it here.
• The Dutch newspaper Volksrant wasted two pages on silly twitter pictures - the article is titled Picfog brengt orde in fotomist op Twitter  which I believe means “Picfog brings order to photo fog on Twitter”.
• DigitalLiving.ch article: PicFog: die Welt in Bildern, aka. “PicFog: the world in pictures”. They also mention we’re web 2.0, which is an extra Brucie Bonus point.
• There was a quick mention in c’t, a German computer magazine.
• Fotointern.ch: PicFog: Unglaublich, was alles auf Twitter hochgeladen wird (PicFog: Incredibly, all of which will be uploaded on Twitter)
• Social media blog Thoughtpick raises the issue of privacy about PicFog - they may have a point, but I kind of like the clean privacy strategy of Twitter.
• Ah, and this is exciting - PicFog was even mentioned in my home country. “Real-time pictures from the twitter fog”, or Real-time képek a twitter-ködből in the ultimate tounge-twister language, Hungarian.

What a month!