Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cutle.fish

Post reply on HN
Print view View original

101–110 of 286 posts

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

#101

Post by gherkinnn »

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…

Having watched recordings of people using our product and spent too much time reading their reviews and feature requests, I can safely say that neither does the average user know what he wants or needs, nor can he articulate what the current problems or improvements are.

It gets worse when you have a specialist of a given field consulting you on how to build software with his field in mind.

“A fish doesn’t think of water” is a fitting quote I once heard.

All you can do is observe, tweak and test.

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

#102

Post by mLuby »

tomnipotent wrote: post #89
mceachen wrote: post #82

Earlier quoted context omitted.

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…

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

Good for you for leaving things better than you found them.

But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey.

Ideally you'd get credit for the good work you do that makes the whole team more efficient.

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

#103

Post by dragonwriter »

sidlls wrote: post #88
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…

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…

> It's disparaging conditions that prioritize the release of features for the sake of releasing features

Perhaps more to the point, it's disparaging having delivering features as the priority instead of delivering customer value.

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

#104

Post by strken »

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…

I don't understand what you mean. A quarter of the items - "no measurement", "no connection to metrics", "no PM retrospectives" - are directly calling out immature development processes which don't quantify success and failure. Many more - "success theatre", "infrequent acknowledged failures", "no tweaking", "chasing upfront revenue" - are the direct result of not knowing whether a project succeeded or failed.

Are your initiatives somehow removing the third step of define problem -> build solution -> learn from solution -> define problem?

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

#105

Post by herval »

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…

As someone working in my 2nd 1000+ developers “feature factory” company, this article describes exactly how things work here in general - and makes for a pretty disfuncional environment. At least in my experience, I think this article is pretty spot-on. If you see yourself just starting to drive to these sorts of initiatives - eg establishing “weekly cadence syncs” that require “wins”, or “virtual squads” as the main team structure, you still have time to ponder and avoid walking that path. Walking back from these cultural shifts is VERY hard.

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

#106

Post by Isamu »

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…

No worries, most of the points boil down to: are you bothering to find out if the feature you shipped actually helped users? Is it actually helping to sell more product or keep existing customers happy?

If you have that feedback, you are good, mostly. Then you will learn to ship what is important to the business.

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

#107

Post by narak »

lsalvatore wrote: post #69
PragmaticPulp wrote: post #39

I suggest re-reading this article in the negative: Assume that your team implemented every single one of these bullet points perfectly, for every feature in every sprint. Now imagine that each of those bullet points is a recurring meeting invite on your calendar. Now imagine how happy you'd be spending all of that time in meetings or reading process-related e-mails so your company could satisfy the criteria of not be…

Ultimately it isn't an engineer's place to complain if they're working for a product that needs 100 more features to succeed in a competitive marketplace and win over customers. I had the exact same reaction as you to this article after seeing it again, and wanted to share why I've also changed my mind on this. I was in "a feature factory" for few years and absolutely hated it. After leaving and going to a "not-featu…

I think a lot of people are missing the point of the article. It's not anti-feature. It's against building features that have no measurable impact to the real goals of any business: better product for the customer AND therefore more revenue.

The problem with the Pyramids analogy is that the Pyramid was the goal. In software companies, features aren't the goal. Better products for customers are. The right features are the means to the end, everything else is a waste of time and an illusion of progress.

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

#109

Post by 0x445442 »

sidlls wrote: post #88
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…

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…

> as determined by data--including analysis of the performance of features, market conditions, and other factors

What would be refreshing are internal ROI dash boards for each project and group instead of just technical dash boards.

On almost every project I've worked on this data is not available and there's never any real evidence presented to the practitioners for things such as tech stack or process decisions. Typically, it's just a bunch of assertions, hand waiving and requests of trust.

Post reply on HN