One cost engineers and product managers don't consider • Hacker News Board

Re: One cost engineers and product managers don't consider

#31

Post by notahacker » Thu, Jun 20, 2013, 9:39 PM UTC

RyanZAG wrote: post #4

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 Gn…

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...

Re: One cost engineers and product managers don't consider

#32

Post by russelluresti » Thu, Jun 20, 2013, 9:46 PM UTC

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.

Re: One cost engineers and product managers don't consider

#33

Post by Ygor » Thu, Jun 20, 2013, 9:51 PM UTC

swalsh wrote: post #28

emingo wrote: post #13

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…

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?

Re: One cost engineers and product managers don't consider

#34

Post by noir_lord » Thu, Jun 20, 2013, 10:02 PM UTC

emingo wrote: post #13

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…

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!.

Re: One cost engineers and product managers don't consider

#35

Post by vacri » Thu, Jun 20, 2013, 10:09 PM UTC

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.

Re: One cost engineers and product managers don't consider

#36

Post by rustynails77 » Thu, Jun 20, 2013, 10:09 PM UTC

russelluresti wrote: post #32

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 engine…

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".

Re: One cost engineers and product managers don't consider

#37

Post by sliverstorm » Thu, Jun 20, 2013, 10:11 PM UTC

Ygor wrote: post #33

swalsh wrote: post #28

Earlier quoted context omitted.

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.

Re: One cost engineers and product managers don't consider

#38

Post by frenchy » Thu, Jun 20, 2013, 10:21 PM UTC

rustynails77 wrote: post #36

russelluresti wrote: post #32

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 engine…

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.

Re: One cost engineers and product managers don't consider

#39

Post by anigbrowl » Thu, Jun 20, 2013, 10:22 PM UTC

notahacker wrote: post #31

RyanZAG wrote: post #4

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 Gn…

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…

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.

Re: One cost engineers and product managers don't consider

#40

Post by russelluresti » Thu, Jun 20, 2013, 10:26 PM UTC

rustynails77 wrote: post #36

russelluresti wrote: post #32

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 engine…

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".

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.