It was just another day at the office when Mark approached me about implementing a new feature for a project we were working on, before he could finish fully describing it, I interrupted him with, "Absolutely not, that would never work and here's why..."

I then proceeded to rattle off a long list of all the reasons why it would never work. Mark patiently listened to my mini-rant and then, with a heavy sigh, responded with something I've never forgotten, "Jay, you never say yes to anything and I'm getting to the point where I don't even want to approach you with new ideas anymore."

Some programmers might wear a response like that as a badge of honor, they might even relish in it, as this commenter on Hacker News shows:

A designer I worked with had lots of interesting stuff taped to his door

My favorite was probably the following:

“Can you just...”

no.

But I had no desire to be perceived as a Negative Nancy like that, and so Mark's response that day completely transformed my attitude about how I approach new feature requests. Now, my default response to most new feature discussions is that of course the engineering team can implement it, it's just a matter of priority.

Some developers will consider this a dangerous answer, but I think if expectations are agreed to ahead of time, most problems can be avoided. The entire team, or company, needs to understand the tradeoffs of the new feature, its ongoing maintenance, and how it affects the overall product.

These tradeoffs are wonderfully summed up in two points of rfc1925:

(2a) No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up might make it slower, but it won't make it happen any quicker.

(7a) Good, Fast, Cheap: Pick any two (you can't have all three).

If everyone understands that anything can be done, as longs as acceptable compromises and sacrifices are made, the conversation can then change from, can we do something? To, should we do something?

I think should we do something is the more important question. If we accept we have the ability to build anything we can imagine, we need to decide if that's how we want to spend our time, because:

Among the most dangerously unconsidered costs is what I've been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer. Sometimes complexity is a necessary cost, but only organizations that fully internalize the concept can hope to prevent runaway spending in this area.

While the author is specifically talking about codebase complexity, I think this also applies to the overall product as a whole, marketing a product that does twenty things is much harder than marketing a product that only does one thing really well, especially if those twenty things span across multiple target markets.

I like to think about product complexity like a magazine subscription. I have packrat-like tendencies that require constant vigilance on my part to keep in check. A few years back I talked my wife into letting me get a magazine subscription, she reluctantly agreed after I told her I would throw the magazine away after I read it.

However, each month I would find one or two things in the magazine that I wanted to remember, so I would mark the pages and put the magazine in the corner so I could reference it later. My three year subscription ended last year, but to this day, there are 36 issues of that magazine sitting in a box in my office.

I can't bring myself to throw them away because I've marked something to remember in each and every one of them, but I also think about how annoying that box of magazines is, and how much space it takes up. That box has even survived a dwelling relocation or two. That's product complexity.

There's a reason why we have platitudes like, KISS, keep it simple stupid! and Good is the enemy of great because we really do need to keep reminding ourselves of what's really important and where we should be spending our time. Complexity in your codebase, and in your product, grows exponentially and can quickly spiral out of control--and paralyze your company--before you even knew there was a problem.