I've never heard of this term before, but when I think of "feature factory", products like Jira and Yahoo! immediately come to mind. Such products feel like a sinking bag of features with no real cohesive, central purpose.
Signs you’re working in a feature factory (2016)
241–250 of 286 posts
Re: Signs you’re working in a feature factory (2016)
#242I'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…
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…
Describes a company I was at very well too. Focus on timelines and delivering some defined scope. Most of the symptoms in the article were present.
Is this just a natural course for startups unless conscious effort is put in to counteract it? I mean in the earlier days of startups just delivering features and catering to customer asks might be a good thing.
Re: Signs you’re working in a feature factory (2016)
#243Most of the points come from disregarding the cardinal rule that every developer and development company should abide to (obligatory IMO): Fight for the users.
In this case, you can't fight for them if you don't know what they want or how the product is helping them.
Re: Signs you’re working in a feature factory (2016)
#244Dear lord this is depressing to read. My personal annecdote here that's probably not a big contribution, but this puts a label so well on the product organization I just left on a large project @ a fortune 50 company.
What's really bad is that the much larger R&D organization (who is I now know to label a feature factory), absorbed our smaller highly productive team that essentially did everything opposite to this. The things we thought we were good at were suddenly the huge flaws of our team - flaws that lead to a number of us leaving to get away from the huge amount of process that got laid on us.
Re: Signs you’re working in a feature factory (2016)
#245I'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…
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 is impossible to verify with as little context as you have given whether this is a good or a bad thing. But it clearly has a lot of bad in it. In the case of an "enterprise software project", the sales process is…
"An example of an alternative that is appropriate for a lot of web companies (for example Google, Amazon and Booking) is an A/B test culture. Release features as A/B tests with transparent metrics. Share the metrics with everyone who is part of the decision INCLUDING devs. Proceed with general rollout of the features that actually produce positive results and rollback of the ones that don't."
If this is the process Google follows, how do its products (e.g Gmail) get worse over time? (genuine question, not snark). Are some things (e.g loading speed) not measured? Perhaps the things measured ('time spent 'in app' ') don't measure customer satisfaction?
Re: Signs you’re working in a feature factory (2016)
#246Twelve out of twelve for my company. Yah us!
Re: Signs you’re working in a feature factory (2016)
#247Earlier quoted context omitted.
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.
What were the circumstances that people were afraid like that? For example, was this an in-house development team, or hired consultants? And how did you find out that people were afraid to ask these questions?
Re: Signs you’re working in a feature factory (2016)
#248Earlier quoted context omitted.
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?
> in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X
This is misleading, you should not be refactoring some other random code. You should be refactoring the code you are adding to/changing as part of the work. And it should be in proportion to the size of the change.
Re: Signs you’re working in a feature factory (2016)
#249Sigh... At some point, most healthy adults who are not living in terrible circumstances come to the mature realization and compromise that their job is largely to produce value for someone else, not to be the primary source of personal fulfillment, and they come to understand that there is dignity in being productive, if not creative. Be creative on your own time. Lead a civic group. Be a good parent. Volunteer at a…
Disagree. This is an endorsement of accepting the fact that your work, your professional work, done by most of us at a job, makes you feel like a cog, a unit of production. It is better called a surrender than a compromise. Surely it's often case that life has people in this sort of scenario and there is no realistic way to a new path. In that case, sure, take care of your loved ones and yourself, stay put, and make…
> It's not mature to accept an unfulfilling job. It's a life-scale bummer. Tenaciously go after fulfilling work. Don't write off 1/3 of your remaining life.
For many (probably most) people all jobs available to them will be unfulfilling. For the rest, many of the jobs can be fulfilling, but have unreasonable demands, like concentrating for 40 hours a week and constant stress.
Obviously everyone's body and mind are different and if yours can easily deal with stress and 40 hours a week of concentration, then go look for a fulfilling job. If you're like me, on the other hand, you will burn out due to weariness even in what is supposedly your dream job. In such case, the only way to win is to make as much money as possible and retire early. The alternative - working while constantly tired and grumpy till you're 65 - is grim.
Re: Signs you’re working in a feature factory (2016)
#250Feature 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."…
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
― Antoine de Saint-Exupéry, Airman's Odyssey