Signs you’re working in a feature factory (2016) • Hacker News Board

Re: Signs you’re working in a feature factory (2016)

#151

Post by nateburke » Sat, Feb 15, 2020, 8:31 PM UTC

As the average tenure of an engineer (or PM, for that matter) at many medium-to-large software companies edges towards two years, it is BARELY enough time for the average employee to 1) ramp up on HR stuff/culture, 2) understand the implementation of an existing system, 3) make and deploy a change to the system without incident.

Best case, all of that takes 6-9 months, but the reality is more like 12-18.

Having time to understand the "why" behind features in a deeply critical way is a LUXURY given this average 2-3 yr time frame. And all of this assumes an absence of reorgs, mission-critical integration work, etc., which further complicate understanding.

The reality is that customer needs are changing so rapidly that even CEOs and heads of sales fail to grasp the "why" most of the time, and merely focus on just doing whatever it takes to win the next big contract. "When one can see no future, all one can do is the next right thing."

Re: Signs you’re working in a feature factory (2016)

#152

Post by joshspankit » Sat, Feb 15, 2020, 8:43 PM UTC

undefined1 wrote: post #145

johnkarahalis wrote: post #8

Feature addiction is real. This post points to perverse economic incentives as being one possible cause, but I have also seen this happen in open-source projects. It's a matter of listening to the wrong people, in my view. User feedback is incredibly valuable, but when user feedback comes in the form of GitHub issues rather than careful testing and conversation, the team will inevitably find themselves building more…

A useful metaphor we use in game dev: Players are the patient, you are the doctor. They're great at finding pain, but not at knowing how to heal it. It's on you to figure out what the underlying problem is and how to solve it. Also, some of my favorite quotes on this subject: You listen to all your fans and they always say "You should add this" or "You should add that." They never say "Take this out, take that out."…

I’m not saying this to argue against your points: I’m a fan of Tangerine bank and have been continually and loudly telling them to remove the balances on the account overview screen as it now triggers “burning a hole in my pocket” psychology.

I only mean to say at least a few fans are actively asking for things to be removed, simplified, and (thoughtfully) refined.

Re: Signs you’re working in a feature factory (2016)

#153

Post by notyourday » Sat, Feb 15, 2020, 8:59 PM UTC

tomnipotent wrote: post #148

notyourday wrote: post #135

Earlier quoted context omitted.

I'm not following - Is it your claim that among FAANGs it is a normal practice to say "This will take X weeks" when in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X?

That these companies don't treat engineers as a cost structure the way you were talking about. This creates a drastically different culture since tech has a seat at the table, and the CFO can't just willy-nilly makes demands that impact the entire engineering organization without consent. It makes a big difference.

> That these companies don't treat engineers as a cost structure the way you were talking about.

That's absurd. The reason those companies are making money is because they are costing every single thing. That's the reason why tech gets a seat at the table -- it is a cost and its top of the line managers understand that this is a liability and drive that understanding through the entire tech organization.

Re: Signs you’re working in a feature factory (2016)

#154

Post by srmatto » Sat, Feb 15, 2020, 9:00 PM UTC

Here is the update to this article, 3 years later:

https://amplitude.com/blog/12-signs-youre-working-in-a-featu...

Re: Signs you’re working in a feature factory (2016)

#155

Post by notyourday » Sat, Feb 15, 2020, 9:02 PM UTC

tomnipotent wrote: post #140

ldng wrote: post #115

Earlier quoted context omitted.

My experience is that implicity is a huge problem as it's too often taken for granted and precisely not valued. Only when you stop doing people realize that since Jeff is on long leave server aren't updated and we've been hacked or that Lucy quited and everything seem to crawl to a halt because she implicitly was doing housekeeping on the database. It might not have failed you yet but be sure the day it does there a…

These are all expected and desirable outcomes. Sometimes technical debt is not worth paying off until your hand is forced, like in these examples. A large part of management is making the implicit explicit, and communicating the outcome of these efforts. None of these examples have anything to do with refactoring code, specifically, and the challenges faced within that work.

The first sentence contradicts the other two and it contradicts the previous position where refactoring was done implicitly without anyone above in the org being aware of it.

Re: Signs you’re working in a feature factory (2016)

#156

Post by hrktb » Sat, Feb 15, 2020, 9:08 PM UTC

Alex3917 wrote: post #25

johnkarahalis wrote: post #8

Feature addiction is real. This post points to perverse economic incentives as being one possible cause, but I have also seen this happen in open-source projects. It's a matter of listening to the wrong people, in my view. User feedback is incredibly valuable, but when user feedback comes in the form of GitHub issues rather than careful testing and conversation, the team will inevitably find themselves building more…

Most times when users say they won't use a product because it's missing a feature: - Those specific users won't use it anyway even if you add it - The problem they identified is a legitimate problem that was preventing other people from using it - Whether your metrics actually go up depends on where that feature was in the critical path of your funnel. All else being equal, fixing legitimate problems with your produc…

> Those specific users won't use it anyway even if you add it

These users often understand what features are missing because they rely on them in other products. At that point your product is already dead to them.

Re: Signs you’re working in a feature factory (2016)

#157

Post by nicksergeant » Sat, Feb 15, 2020, 9:20 PM UTC

joshspankit wrote: post #152

undefined1 wrote: post #145

Earlier quoted context omitted.

A useful metaphor we use in game dev: Players are the patient, you are the doctor. They're great at finding pain, but not at knowing how to heal it. It's on you to figure out what the underlying problem is and how to solve it. Also, some of my favorite quotes on this subject: You listen to all your fans and they always say "You should add this" or "You should add that." They never say "Take this out, take that out."…

I’m not saying this to argue against your points: I’m a fan of Tangerine bank and have been continually and loudly telling them to remove the balances on the account overview screen as it now triggers “burning a hole in my pocket” psychology. I only mean to say at least a few fans are actively asking for things to be removed, simplified, and (thoughtfully) refined.

You're asking a bank to remove visible account balances from a dashboard view?

Re: Signs you’re working in a feature factory (2016)

#158

Post by TeMPOraL » Sat, Feb 15, 2020, 9:31 PM UTC

BlueTemplar wrote: post #123

ehnto wrote: post #113

Earlier quoted context omitted.

It would be important context to know if this is an agency or a product owner company. There is a whole spectrum of client-agency relationships, and some of them are more like a feature factory than others, and there's nothing wrong with that. Some companies want to hire a development team to work as if they were in house developers. Some clients just want to ask for Feature X and have Feature X delivered. They keep…

The general rule though is that the clients are asking for X, actually need Y, and get delivered Z - isn't it?

That depends on who the clients are, and why did they hire you. If you're just a subcontractor in an org run by smart people, it may very well be that they're asking for X, actually need X and expect to get X - they just outsourced the boring work to you.

Re: Signs you’re working in a feature factory (2016)

#159

Post by _y5hn » Sat, Feb 15, 2020, 9:38 PM UTC

tomnipotent wrote: post #146

hamiltont wrote: post #130

Earlier quoted context omitted.

A challenge I keep hitting with this is non-technical team asking 'why it takes this long' anytime the provided date is >X (for some X is a day, for others it's a week). They want to understand the internals of the ask so they can then nitpick that "well that's not needed". Fundamentally it's a lack of trust IMO, but any tips on addressing this would be welcome :-)

> Fundamentally it's a lack of trust IMO Which is usually a failure of communication. The whole "just trust us" bit doesn't work, and it takes real work to build a rapport with your stakeholders to earn "blind" trust, which is what most people are really asking for when they say "just trust us". This almost never happens, unless people have been working with each other for many years. > then nitpick that "well that's…

This only works for management, who are not actually doing any of the tangible work, but doing diversion work instead. For the kindergarden style teams, there are multiple non-productive diversion people already telling different stories to various other functions of the company. Then you have the next legs beyond that telling wilder stories. The dysfunction only grow worse as the system tries to scale the dysfunction.

Today most of business side has simply become too incompetent to be able to complete a dialogue with devs. Same goes for dev side, but is nothing new.

Re: Signs you’re working in a feature factory (2016)

#160

Post by joegahona » Sat, Feb 15, 2020, 9:39 PM UTC

lazyjones wrote: post #77

dillonmckay wrote: post #54

Earlier quoted context omitted.

I strongly disagree with this sentiment. I’ve seen quite a few features added simply ‘because we can’, without any thought to ongoing maintenance, support, or additional infrastructure requirements/costs. A little bit of common sense and forethought can go a long way in preventing unprofitable or revenue-decreasing features from being added to the product. If you keep adding features, without increasing your conversi…

You are basing your sentiment on assumptions that cannot be verified in practice without implementing/releasing the features. Nobody wants to implement revenue-decreasing feature but nobody knows beforehand whether they will increase or decrease revenue. So such statements are useless.

There are lots of ways to test and to map potential features to customer problems. Launching features because _you_ think they’ll resonate with users is a complete crapshoot. More often than not, people inside the company are way too close to the product to be able to determine which features are the right ones. I recommend “The Right It” by Alberto Savoia, “What Customers Want” by Tony Ulwick, and “The Lean Product Playbook” by Dan Olsen if Cutler’s essay doesn’t convince you.