One cost engineers and product managers don't consider | Hacker News Reader

One cost engineers and product managers don't consider

firstround.com

296 pointsjkopelman99 comments

For years, the two things that most frustrated me to hear from product managers were "how hard would it be..." and "can't you just..." It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases.

Oh, man.

When it comes to my natural reaction to this, the words 'strong and visceral' doesn't even do justice.

It took me a really long time to understand why I had such a deep-seated loathing for phrases like that. Think of some absurd scenario where someone asks you to cause harm to yourself, so they can benefit in some way, and that's how I would respond. I basically translated these requests to something like, "can't you just shoot yourself in the foot, so I can sell your toes?" and reacted accordingly.

This post provides some good examples -- explained in a much more objective and rational manner than I've been able to -- of the cost, and why this bothered me so much. In general though, if engineers have to spend a lot of time mitigating "can't you just...?" then I think it may point to a more systemic problem in the organization. Namely, the business units are so disconnected from engineering they don't even realize the costs of what they're asking for, and the engineers are so disconnected that they reap zero benefit from whatever business goal is going to be accomplished by this.

I'm actually okay with shooting myself in the foot to sell my toes every once in awhile. I just don't want to do it if everyone else is going to make money from selling my toes except me, and they don't care about giving me time to rebuild my foot afterwards.

> the business units are so disconnected from engineering they don't even realize the costs of what they're asking for

In software you get this at all levels, including in the freelance/consulting world - people have no clue of the costs of what they're asking for so when they can't even make bad guesses, they go with "how hard would it be..." for a big feature request or "can't you just..." for what they see as a small one.

I always prefer honesty over this - if you have no idea about even estimating the cost for some feature, just ask "How much will it take and how much will it cost to... ?", don't fuddle around with the "how hard...", "can't you..."... these are just weasel words for when you need to overwork and underpay someone because you really know you need something done yesterday and with almost no budget, but you really need it so maybe someone will just shoot himself in the foot to make it work for you if you ask nicely enough :)

You're putting way too much baggage on to "how hard". It doesn't necessarily carry any implications of "yesterday and with no budget"; it's a scoping question.

"How much will it take and how much will it cost to... ?" condenses down to "how hard…". You can tell they're functionally equivalent because you can give the exact same answer to both.

"Can't you just" is a whole different story, granted.

I somewhat agree with you, it's not "dishonesty", but when people phrase it like "how much will it take and how much will it cost to..." they usually have in mind the fact that it will take time and have a cost, whereas when they use the condensed variant, they tend to think that it can be "squeezed in there and worked on at the same time as everything else without delaying anything" ...it's folk psychology I know, but imho there's a more or less subconscious association between using the condensed form for talking about something and wanting to minimize the apparent cost/impact/etc. of it :)

The people asking probably don't think they have no clue of the costs of what they are asking for, they think they have a vague idea of the relative costs based on their perception of what is involved and their past experience of other changes.

Now, these ideas may often be very wrong, and may be in fact so wrong that "no clue" is the best description, but its not, for the most part, dishonesty when people act like they have some general expectation of the cost.

The worst are inexperienced product managers who look at you like you're trying to pull a fast one.

If it's something small, then maybe just code it up quick in a branch named after the PM-Feature (so you can keep track). Then ask them to validate the requirement before you merge it in (hopefully you can help with this). At least this way they know that you aren't being lazy etc.

Next time that PM asks for something "simple", do a quick branch list of invalidated feature requests.

I've had some luck defusing these kinds of remarks by calmly but firmly stating that "with though simplifying assumptions, anything is trivial". YMMV.

"with though simplifying" doesn't sound right to me....did you mean something else?

Context tells me he meant "with enough"... touch screens are a wonder for us fat fingered folks.

The mobile experience on HN sucks.

Keyboard input on someone's phone is not something HN would be able to fix.

On my Android browser, I am usually typing with the box half-off-the-screen so I can't see what I've typed. On Android Chrome, font size for replies is incredibly inconsistent (some comments are huge and some are too small to read, and some are inbetween), and the textbox is still half-off-the-screen.

The text size issues is a bug in Chrome. Firefox for Android has a similar bug as well. For this reason alone I switched to Opera; it has its own bugs, but at least the text size is right.

D'oh! Of course I meant "enough".

A designer I worked with had lots of interesting stuff taped to his door, and rotated it regularly.

My favorite was probably the following:

“Can you just...”

no.

Yeah, I find that attitude quite counterproductive in software development. I understand and agree with the argument that some “can’t you just”s are way more complicated than they are presented. But this kind of attitude, taken to its extreme (e.g., having that sort of half-joking sign on your door) is a roadblock to real progress, which often starts with a “hey, couldn’t we...”.

For me the point is that inserting the word “just” is diminishing or belittling the person's contribution, even as you are asking them to make that contribution.

I actually see these as an opportunity to improve existing code, plus doing something new and different. However, to cover myself, I ask for thorough specifications and test-cases, to which I add risk analysis etc. If it doesn't go exactly right, I blame the specifications.

Your product managers need to understand enough about the quality of the different areas of your system to know what you are talking about when you say that something is easy or hard. It's best to make that a part of your regular discussions rather than something you pull out when there's a problem.

Draw them a picture and have the discussion - frequently.

"Namely, the business units are so disconnected from engineering they don't even realize the costs of what they're asking for, and the engineers are so disconnected that they reap zero benefit from whatever business goal is going to be accomplished by this."

I don't think it's just that they're disconnected - some of the orgs I've been in - they simply do not care, and never will, even if they completely understand the "costs". Why not? Because they don't have to pay it. It's not coming out of their budget, the 'costs' of higher support later on don't affect anyone who's making the decision right now, and damnit, we have to get this out now or we'll lose marketshare!

This is a toxic division, and seems to be more prevalent at companies that do not see themselves as software-based companies. Yammer is all tech - Yammer couldn't have existed 30 years ago, but plenty of more traditional companies still see software as something divorces from their main business.

I have similar experiences - it all comes down to accounting structures, in the end.

It happens in tech companies too, especially enterprise companies. Project managers want to close out on their project and deliver to their customers and fuck anything else that's going on.

I've had a lot of success explaining it like this:

"Making something work is pretty easy. Making sure it never fails is the hard part."

Good article, makes an important point about complexity.

Just want to add one extra thought though:

  he or she will run reports against the usage data to find
  out whether a given feature is often used. That data can
  then be run past the product managers who can help decide
  whether it's sensible to just drop the feature.

It's important to be careful here, and it's one of the traps that is very easy to fall into (see Gnome). Just because a feature is only used by 1% of your users doesn't mean it's not important. You might have 100 features only used by 1% of your users each, but if you take out all 100 features, chances are you've taken out at least one feature that every single one of your users depends on, and now your product is a lot worse instead of better.

You could also drop a feature used by 1% who just happen to be the 1% who make the buying decisions or are vocal.

I call these User Landmines (they are quiet right up until you step on one).

On a similar note, this bit caught my eye:

It's often subtle or intentionally hidden features that cost the most in the long term. Yammer has long had a feature that allows you to begin a message with "to:" and a username to send a private message to someone, or followed by a group name to post to a group. This probably took me an hour to implement, test and deploy back in early 2008. I have easily spent 40 hours of my time -- and, necessarily, 40 hours of others' time -- over the intervening 5 years explaining this feature and its justification.

One likely reason why an engineer - as opposed to a sales or customer support rep(1) - might end up spending as much as 40 hours explaining and justifying a trivial, implemented and documented feature would be a culture obsessed by removing perceived cruft.

(1) If competent sales or customer support reps spend 40 hours talking about a feature then some conceivable variant of it has some perceived value to someone...

I have to say that two man-weeks in 5 years for a feature with pretty high utility doesn't seem that much of a burden. However, I'm quibbling over words- I agree with the general thrust of his argument.

That's how I feel about Apple deeming unimportant my Home, End, PgUp, PgDn, and front-delete keys.

RIGHT ON, BROTHER!

Just in case you’re not aware: the Fn key, in conjunction with the arrow keys or the delete key, let you type those keys. Though that’s certainly not as convenient as having dedicated keys.

Also, you can remap different keys to those keys with the free software KeyRemap4MacBook (https://pqrs.org/macosx/keyremap4macbook/index.html.en). For instance, you can remap \ to be forward-delete and Fn+\ to be typing ‘\’.

That's fine and good, until you want to use key combinations that include the missing keys, particularly selection type stuff. For me, it comes up a lot in programming, writing, and file/photo management.

I find that Shift-Fn is particularly easy to chord since they share a boundary. I usually use pinky on Fn and ring finger on Shift.

We hit this at MSN: we removed the "print" button from all articles. Result? Engagement in Japan fell. Why? Apparently, printing out a sheaf of articles to peruse on the train is (or was) a thing. Solution? Re-enabled the "print" button in Japan; everyone else was saved from downloaded the unused-in-market "print" button, lowering PLT.

Please keep in mind I'm talking about stuff from about five years ago when you run to MSN.jp looking for print buttons.

Seriously doubt this has changed, even now Japan sells millions of fax machines a year domestically, Japan loves paper.

Problem is then that you have two cases that need to be tested and taken into consideration when designing etc.

No one is using this password reset feature, lets drop it.

The title of this article doesn't make sense to me, as an engineer, working on a team of engineers.

Complexity is always something we consider - in every team I've ever worked on. DBA's always talk about the complexity of the data. Dev's always talk about the complexity of the code base. And UI Dev's and Designers always talk about the complexity of the UI.

No one understands the cost of complexity better than engineers. We understand the increase in the likelihood of bugs, or the increase in maintenance and refactoring costs. We understanding that making a UI complex means users may have difficulty learning how to complete a task and get frustrated, and we understand the costs of those frustrations.

I'm not sure why this person thinks engineers and product managers don't understand the cost of complexity. In my personal experience, it's always been business and sales people who don't understand how adding a shiny new feature could be harmful in any way.

As an engineer, my personal experience is that most feature creep actually comes from engineers. Marketing usually have the least idea, but engineers usually cause the "death by 1000 cuts".

In my experience, this is usually the project managers. The engineers would love to remove the unused cruft, but the project managers don't see it as beneficial and always make other priorities.

I think the only time I've seen engineers add feature/code creep is when it's "filling the gaps" that others didn't think of. Many times ideas are presented to engineers in their unfinished format. It's often up to engineers and QA to find the areas where that idea needs to be fleshed out. Fleshing out an idea, I would argue, isn't feature creep but trying to make an added not suck.

Yup. When you've got a system that, as implemented, gets you 99% of the way to a nifty but unrequired feature? It's dreadfully tempting to go that last 1%. But somehow that 1% balloons into being something that you have to support and the UI turns out messier than you expected and yadda yadda yadda.

The first comment on that page sort of made me face palm... but then it got me thinking.

"Simplicity of usage should always win over simplicity of coding. The purpose of a product is to solve the end user's pain, no one should give a dime about the engineer's problem. IMHO that was the genius of Steve Jobs, he could take any pre-exiting product and increase its complexity by 50x while simplifying its usage by 10x."

I am relatively new to coding, and really, I want to know what do you guys think about this? Does this really scale? Does simplifying the front end often compromise the backend?

>Does simplifying the front end often compromise the backend?

Sometimes but not necessarily unless you're making a programming language or a platform. For typical, more direct cases it's not necessarily the case at all.

In my experience, any interface that does not directly conform to the underlying technology is going to increase the amount of work (aka complexity). And typically, the reason why one interface is simpler than the other is because instead of conforming to the environment/language, the engineer had to code another way to do it.

It depends on what stage this is done at. Imagine everything is linked to a user. How hard would it be to allow anonymous posts?

The two are not mutually exclusive, and solving both of those is what makes programming hard and fun.

> Simplicity of usage should always win over simplicity of coding.

In a superficial assessment, yes, usage is the objective of software, and it should be as complex as needed to enable its users to have an optimal perfomance.

But then, most software is built in an environemnt where people don't even know* what problem they want to solve beforehand. Ading complexity too early makes it very hard to change your software and leads to a situation where you completely optimized some work that shouldn't be done at all, while the important work got harder because it was overlooked at first.

* They have a general idea, and even that is wrong sometimes.

Its a false duality. It assumes complexity is zero sum, either the user has it or the programmer has it. In my experience this is not true.

But, doesn't maintaining both implementation complexity and product usage complexity low require either more development time or better developers?

Reducing either form of complexity certainly costs resources, but I think the point is that they are not necessarily antagonistic goals- they might even come as a package deal, to some degree.

There's a whole spectrum of users, as well. Programmers can be Python users, wherein the python implementation takes complexity hits to simplify it for the user.

It's all subjective, and the design of the high level concepts (maybe mechanics?) influence the complexity at every level below it. The idea of a 'file' goes from the GUI down to the hard disc format.

Also based on his figures if you increase the complexity by 50x and simply its usage by 10x...you still made it 5x harder to use!.

I think that first comment completely misses the point of the article. It's not a matter of whether or not you should or shouldn't make things simpler for the user. It's that you shouldn't view changes as one-time costs - you need to take into account the lifetime maintenance cost of that change you will have to live with. Many times, it is worth the cost because it solves the end-user's problem, that's true. But the point is that we often don't even consider it.

(5) It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

--RFC 1925, http://www.faqs.org/rfcs/rfc1925.html

I highly recommend reading RFC 1925: The Twelve Networking Truths. It's a much faster and more amusing read to get the same information.

In my experience, practically everyone agrees that software should be simple, but not everyone agrees on what simple is.

Unfortunately, that hasn't been my experience. Everyone wants software to be easy, but most people (by which I mean clients, management, and anyone else who's ever asked me to build software) have no opinion one way or the other about simplicity: They want it to do exactly what they want, the way they want, regardless of how technically feasible or user-friendly that ends up being.

Simplicity is an ideal I see a lot more among tech people (myself included), and while I think it's nice to aspire to, it's definitely not something I've seen as a request, requirement, or even preference among the kind of people who are willing to pay others to build things. They want what they want, not a simple implementation of what they need.

Perhaps the reason I haven't shared your experience is because I primarily deal only with tech people.

As another child comment identifies, we should not confuse simple with easy. Clients want easy software, and they have little care or understanding of the complexity. That's OK, on its head, but it is our responsibility to share and teach this side of the software's lifecycle with "management" and "junior" developers. Rich Hickey, author of Clojure, had a great talk on simplicity and easiness of software [0].

[0] http://www.infoq.com/presentations/Simple-Made-Easy

Simple is good, but the thing you really want is orthogonality - the ability to change one thing without affecting another. Generally, you get that by moving toward small, focused abstractions.

Wow, that one really resonated with me. I hadn't really thought about how to put simplicity into perspective quite like that. One of the things that frustrated me about Windows was that there was always about 7 different ways to do the same thing (or get to the same place) and that lead to amazing time wasting discussions in attempting to support customers remotely.

Google has (had? I suspect they still do this) company wide 'fixit' days where people would fix bugs for prizes and what not. I suspect a 'delete-it' (or 'simplify-it') might be a useful exercise as well.

We still have fixits and we also have delete-it's as well. The team I'm currently on has Delete Tuesdays where everyone competes to delete unused code or config options. It's very satisfying.

Whammed in the face with:

"Subscribe to receive future articles right to your inbox"

Tab closed. To hell with them.

I kept reading but definitely found it annoying.

It also took a few seconds to load and the page scrolled back to the top, causing me to lose my place. Extra annoying.

Agreed!

something in one of chrome, ghostery, disconnect or adblock removes that, fwiw (and maybe it's just because it's timely, but it's actually one of the better posts i've read in this kind of thing).

I have adblock and ghostery. It still appeared for me.

Perhaps I should use noscript as well :)

I rarely see this stuff in w3m ;)

I've been pushing this idea for the past couple of years with clients, and when I give talks at conferences. The fact of the matter is that unless an organization knows what the carrying cost is for their features, and the effect in terms of complexity, they are flying blind.

In essence, it is Joel's Law of Leaky Abstractions at work. You can't manage a software project just in terms of a set of features you agree upon with business. The codebase is a key constraint that underlies all of those discussions and unless the effects of feature choice are on the table, you end up incurring radically different costs.

This isn't just about paying attention to technical debt. It's about having the discussion about whether it is worth targeting some features or not, taking the code into account - using it as a factor in business decisions.

http://www.confreaks.com/videos/717-rockymtnruby2011-opening...

http://michaelfeathers.typepad.com/michael_feathers_blog/201...

Totally agree. The last company I worked for would agree to add basically any feature someone requested, even if it was of no use to anyone else. Most of the time spent implementing these odd features was making sure they'd work with all the other possible combinations of odd features, just in case they were ever used in tandem. They never were. The project I worked on was in its 4th total overhaul when I left, and they still hadn't actually sold a single copy.

An oddly lengthy article considering its topic (simplicity).

Useful nonetheless. It puts into words the visceral reactions we have all had at some point to "How hard would it be to...?"

Would anybody speculate that the popularity of MVC and agile development has exacerbated this issue?

I'm working for the first time on somebody elses code and with a group of develpers, and it seems like the answer to most problems is 'just add another model'. I stay away from that as much as I can, and try to make existing models fit new features and functions.

Maybe it's just my current workplace, but is this a more modern problem?

if you aren't allowed to spend more than 1-2 days writing and testing any particular unit of work, agglomeration is the dominant strategy.

I'd rather have two simple things than one complex thing.

In the codebases I've worked on, a lot of the complexity I see arose from people changing the meaning of existing code so they could 'reuse' it.

Writing software is all about managing complexity.

HN had another article a couple weeks ago asserting you shouldn't add business processes to your company unless they had an expected value of increasing foo by at least 10%. The author argued this was a good way of avoiding creeping bureaucracy. It's striking how similar that is to this article's thesis re code complexity.

Complexity is also introduced by well-meaning people on the implementation side as well. Software developers like challenges, and the challenge of building a complex system that serves up a simple interface is especially alluring. Consider DSLs, abstractions and the attraction to being the one to build a framework that gets leveraged for years. This drives us to introduce huge complexity debt we defend with statements like "it makes it so easy once you understand" and "it will save us so much coding." Writing the lines of code is rarely the big cost in engineering: it's the understanding, the communication and the maintenance.

Ok, but did it save so much coding, or not? I do try to restrain myself from being clever when I realize it's really not worth it, but being clever sometimes does pay off. Extra coding is complexity too.

That said, making a simple system that provides a simple interface to a complicated (or at least, a sophisticated) issue, is much better. And, you don't have to control your ego either. You can learn to take pride in the expressiveness and simplicity of your code.

I've frequently heard designers, developers and VPs of Engineering -- which I'll collectively call "builders" -- argue that a product should have fewer features and thus should be "simple."

But I honestly can't remember reading once when a user has said they want fewer features. Users want it to easy, yes, but they also want the features that make their lives, well, easier; see how that works?

Whenever I hear builders argue for simplicity I get deja-vu as if I'm hearing union members argue against those who might cross the picket line, or lobbyists trying to convince congress to give their clients tax breaks, or record companies complaining about downloaded musics, or, or, or,... well you get the picture.

I think fewer features isn’t something a user would request. Fewer features is just something they would notice the absense of. Users don’t always know what they want.

For example, there may be a ten-item menu where the user only uses the two features at the bottom. The user is slightly annoyed every time they have to move the mouse all the way down there to select that feature. But it probably wouldn’t occur to them to ask that the other menu items be removed – they are just trying to ignore those items.

What users say they want and what they will actually use are often completely different.

Is it poor submission titles?

Is it websites that pop up a subscription box with no obvious close button?

Title should be: The one "feature" that will cause users to practically insta-close your website and not read the article.

A lot of this is heading off complexity at the beginning. Every new feature should come with "Do we really understand why we're doing this?" It's ok to experiment, but prune prune prune....

As an engineering manager I have struggled many times trying to convey the real cost of these 'cant you just do this...' type of things. This article makes a clear case in a structured way.

I haven't run into many product manager that would understand the cost management exposed here. Most product development company I have been at avoid discussion/debates around the real cost of some of the development.

I'm not sure whether it's the lack of understanding, or simply the lack of interest for long term impacts sometime outlived by exit strategies.

Brilliant article.

I have made similar observations in the past as well:

http://williamtpayne.blogspot.co.uk/2012/05/complexity-it-ha...

As well the mistakes we tend to make when we try to deal with it:

http://williamtpayne.blogspot.co.uk/2012/06/pushing-complexi...

How do you know when you're making it too complex? On one hand you have Hello world! And on the other the vilain project manager requests.

But say you design a distributed system and its protocol, how do you know what is to keep and what is to delete ? We know the problem of over quality or complexity, but how do you know you're just right?

My feeling is that beeing too minimalist might refrain progress and discovery of new loved features.

like a commenter suggests on the original post, end users don't care how something is built, but how well it solves a problem of theirs. It's like drucker saying costs have nothing to do with price. So, you can build things with bloat but it'll put you out of business. You also have to do right by your users. Not doing stuff because it's hard isn't a good excuse (a lot of the time).

In short: KISS (Keep it Simple, Stupid)

That's one of my favorite principles of software development (and engineering in general).

Maintenance is 200% of the cost of writing software.

The first 100% of the cost is 20% writing, testing and certifying it, and 80% maintaining the result.

The additional 100% is the cost of rewriting it because you didn't actually write it to be maintainable.

Features are what sells products, the cost is that they make the product more complex (and add to the cost).

Simple products are often easy to use, and document, which is one of the reasons Apple does so well.

Solving problems sells software - features are just one way of getting there.

To be clear, the author is talking about simplicity which comes out of years of dealing with complexities. The better I get at engineering the simpler are my solutions.

I loved the article, and I like how the author implores us to extend the drive to reduce complexity to how we speak about products.

Could not agree more. Very good paper!

really good read

Users don't want complexity, either.

This is not true. Users want a manageable and appropriate amount of complexity. Sane defaults, reasonable options.

In the sitcom 'Allo 'Allo, a woman is trying to set up a date with a character who's a stickler: "What if I am late?" > "Don't be late" > "What if I am early?" > "Don't be early. Be punctual."

I'm reminded of this whenever I see something on the minimalist vs flexibility wars. The answer is in neither camp, it's in the 'be appropriate' camp.

> Users want a manageable and appropriate amount of complexity. Sane defaults, reasonable options.

without reading the article, I guess it's communication.

it's system complexity and how that makes it hard to maintain, change or validate.

Reply on news.ycombinator.com