Scott Porad

In response to my post about how “Build-Measure-Learn is a waste…if you don’t Loop”, Olivia Zinn and I exchanged these messages:

Olivia: One thing I’d add to your post might be that you have to go into iterative efforts fully open to the fact that the “Loop” step might mean you took at wrong turn and need to stop and/or kill what you’ve done. Otherwise, you wind up with Winchester Mystery House product and resources spent supporting worthless crap. And killing something off is suuuuuuper hard to do, from what I’ve seen. But it’s part of that whole “committing to the Loop”…that’s the toughest part.

Me: I’m not a good killer.  I love all my children.

Read the rest of this entry »

…if you don’t “loop”.  People…you are killing me!  There’s a reason it’s called the “Build-Measure-Learn Loop” and the most important word in that phrase is the “loop”!

Okay, take a deep breath…let me Take a Step Back™…because I started with the conclusion.

All the rage these days is talking about iterative development and emergent design.  If you’re in the business, you know what I’m talking about.  If you’re not, a bit of background:

Read the rest of this entry »

My thoughts on QA drew one amazing comment by Justin Bozonier.  It’s reprinted here for your pleasures and enjoyments!  (Quotes from my original post are in italics.)

This is going to read really harsh. I’m just being as succinct as possible.

“If you’re running a web site, your users are going to find bugs faster than your testers.”

Read the rest of this entry »

A quick note in response to an email my friend Brent sent today:

I recall an earlier conversation about your position on QA – and how you were adamantly against it.  Do you have any blog posts / articles that elaborate on your position? I wanted to circulate it here at [my current employer] – the devs and I have been having some lively discussion.

I wouldn’t say I’m “adamantly against it”, but I don’t think the ROI is high, and for most situations they’re not worth it.   Why? Read the rest of this entry »

Yesterday, my team observed that we’ve had fewer bugs to deal with lately because we shipped less code in the last two weeks.  That caused me to whimsically tweet:

I wasn’t expecting any responses, but received the following:

Read the rest of this entry »

On my SXSW 2013 post, Scott Schwartz left a comment asking:

You ran out of time in your SXSW session before some of us…were able to hear about what a good DEV dept structure looks like and how it scales from 3 designers to 10 and so forth. Could you elaborate or share thoughts on that in a future post?

…sure, here you go:

Read the rest of this entry »

As developers, we spend a lot of time tinkering with techniques and processes for creating better technology.  But, how often do we think about the soul of our technology?

Perhaps the secret to success can be revealed by understanding the mysteries of people who make it, their values and identities, loves and fears, and the narratives that tell the story of their lives.

I shared my thoughts on these topics at the Bacon Conference in London in April 2012. Read the rest of this entry »

Over drinks on Saturday night, a friend shared that he quit the software business after 18 years as a professional software developer.  MIT grad, Anderson consultant, multiple web and software startups, and now done.

I’m just sick of it, he said, of the constant struggles and hassles.  And, after this long, it’s not interesting any more…it’s the same problems over and over again.

Now, he has a job as an “Excel jockey” running spreadsheets as a financial analyst for a property development firm.

Read the rest of this entry »

I recently gave a talk about the philosophy I have for setting up a dev shop.  The slides are below.  It might not make sense without the narrative, but since a number of attendees asked for them, I thought I would share with everyone.

Recently, Eli sent me an e-mail asking:

Do you have any thoughts on writing code to create a solution vs. finding code for that solution? I understand that there are tradeoffs, but do you have any guidelines that you keep in mind?

At Cheezburger, I always prefer to find (i.e. buy or get open source) code over writing our own.  I want for us to exhaust our third-party options before “rolling our own”.

Some of the people on my team are inclined to write things that I don’t think we should. I don’t doubt the team’s ability to write these things. And, it’s often easier up front to just write versus research and integrate alternatives. But, in the long-run (or even medium-run) the total cost of ownership (TCO) is greater when you write.

Read the rest of this entry »