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

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

#131

Post by 0xff00ffee » Sat, Feb 15, 2020, 7:32 PM UTC

I've had to make the decision to steer my design resources into "feature factories" because my customers are sometimes fickle.

There are a number of instances where features were paid for, developed, and then not deployed.

It hasn't become discouraging yet because there has been professional growth in developing methods for constructing and deploying said features, but I am concerned as to our financial ability to identify and reject contracts that are just un-exciting features. Most of my devs are satisfied with the paycheck despite the work, but a few are showing signs of not being valued. And I'm not sure how to address that yet to avoid losing them. It's like: taking a lame contract for $$$ vs. boring a good employee. I hate how personal it becomes, I feel like I'm cajoling them to do the work, ... it feels icky and toxic.

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

#132

Post by metalgearsolid » Sat, Feb 15, 2020, 7:33 PM UTC

Been there. Anecdotally, a good indicator of a feature factory is the turnover in marketing, a particularly gruelling department to be in when you are not finding any consistency with the message you've been tasked with communicating. That kind of situation is okay and perhaps even fun if you can count your colleagues with your fingers, but at companies larger than that, the general lack of understanding of what your software does is a kind of debt, perhaps even classifiable as technical debt.

I tried to raise red flags to my bosses when our colleagues in customer support we're making feature requests for features we already had. The company as a whole lacked the courage or enthusiasm to tackle those design flaws, and instead would request additional features. I tried really hard to fight for removing features too...

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

#133

Post by PAGAN_WIZARD » Sat, Feb 15, 2020, 7:35 PM UTC

scribu wrote: post #7

ttoinou wrote: post #5

What's wrong with feature factory ? If you're delivering something good for clients.. No measurement / Success theater / core metrics This takes time and mental space. That you could better use to... crank a new feature! :)

> If you're delivering something good for clients... That's the crux of it, isn't it? How do you know that what you're delivering is any good?

For some software products, the runtime and output can be measured for quality.

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

#134

Post by BlueTemplar » Sat, Feb 15, 2020, 7:36 PM UTC

enjo wrote: post #67

lazyjones wrote: post #33

Earlier quoted context omitted.

> churning out features without thinking critically about why, your work might not even change the company Isn't this just speculation? Why would anyone build features without any thoughts about their benefit? In practice you never know how a feature is going to work out and benefit or harm the company, you just have to try it. Not trying is a sure way to lose to bolder competition.

There are lots of bad actor reasons (putting career advancement ahead of product success), but there also structural issues that can lead teams to operate this way. The most common: product decisions are made higher up by well intentioned leaders who lack the product management expertise and the context the team does. Usually this looks something like a sales person hearing from a couple of customers “we really need…

I hear that these situations exist, yet this is the complete opposite of what I was taught, which is that (at least !) the project manager had to have frequent and direct contact with the customers starting from trying to figure out what their real needs are - for the project to have any hope to succeed?

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

#135

Post by notyourday » Sat, Feb 15, 2020, 7:37 PM UTC

tomnipotent wrote: post #127

notyourday wrote: post #117

Earlier quoted context omitted.

> Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly. This is the thing that I cannot agree with what so ever. Companies do not employ developers to write beautiful code. Companies employ developers to write code to support…

Show me great companies that follow this philosophy? You definitely won't find them among FAANG, or most of the companies the HN crowd lean towards. There's a limit to when the invasiveness of bean counting is useful, and finding that limit is paramount.

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?

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

#136

Post by bob33212 » Sat, Feb 15, 2020, 7:41 PM UTC

userium wrote: post #129

sidlls wrote: post #88

Earlier quoted context omitted.

This article isn't disparaging having a process for developing features or for maintaining a pipeline of features. It's disparaging conditions that prioritize the release of features for the sake of releasing features as opposed to for supporting the business' needs (as determined by data--including analysis of the performance of features, market conditions, and other factors). This article describes the last company…

Exactly. Feature factories build features based on random assumptions, and not based on actual data. I just wrote about this yesterday ( https://teamsuccess.io/hdd ). I work as a consultant with lots of Scrum teams, and many devs feel like they're just sitting in the factory, cranking out features. Without knowing whether they're adding real value to the end-user. So what can you do to break free from the feature fac…

In my experience people are afraid to ask that question. The answer to that question may lead to questions around total addressable market which could cause uppermanagement to question the viability of the product or at least the cost / benefit of having a big development and product management team in the first place.

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

#137

Post by dragonwriter » Sat, Feb 15, 2020, 7:43 PM UTC

mceachen wrote: post #82

jugg1es wrote: post #65

I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement. It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs…

The article is not saying "big feature" pipelines (where there is coordination across several teams) are inherently bad. The article is disparaging that process if it is the only process. (And I've worked at companies where this was nearly true). There must be efforts to experiment and refine (and possibly remove) existing features. There must be efforts to refactor and improve existing code, to make it easier to mai…

The practices you discuss are incidental, the real criticism the article makes is that there must be focus on measuring and delivering customer value; that h focus must be on impact rather than a train of features.

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

#138

Post by ericmcer » Sat, Feb 15, 2020, 7:49 PM UTC

There is also a perverse incentive for employees to point this out. Why would a product manager highlight that the status quo is flawed? Why would an engineer shake stuff up and optimize tired old code instead of just cranking out a shiny new features?

Raising these issues would ruffle a lot of feathers. I would not do that just to make my own life more difficult and possibly point out that my own position is redundant.

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

#139

Post by logicallee » Sat, Feb 15, 2020, 7:52 PM UTC

I don't know, everyone. All the best software is so great because whatever you want to do, you can find in 1 minute with a Google search. I hate googling and finding "I don't think this is possible. I know you can do this in (a feature factory competitor of what you Googled) but I don't think (what you googled) has this feature."

I've seen comments like that thousands of times. Haven't you?

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

#140

Post by tomnipotent » Sat, Feb 15, 2020, 7:55 PM UTC

ldng wrote: post #115

tomnipotent wrote: post #89

Earlier quoted context omitted.

> There must be efforts to refactor and improve existing code Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly . This has yet to fail me. Granted, I don't work in embedded systems and my code is deployed on owned & operate…

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.