Live data from Hacker News

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

cutle.fish

191–200 of 286 posts

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

#191
post #10

I don't actually understand what's bad about this, maybe someone who is in a company like this can explain why it's a negative? I am working with a company that is moving more towards this approach and I'm really enjoying it. Isn't this essentially what Basecamp's Shape Up method advocates for? Not everyone feels they need to be building something that changes the world I suppose. Each to their own.

It is bad if you don't properly measure the impact of the features.

There are some features that seem like obvious wins on paper but actually do worse when you A/B test it.

They hurt business value and add needless complexity to the development process.

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

#192
post #159

Earlier quoted context omitted.

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

There are too many broad generalizations to find any specific arguments. > Today most of business side has simply become too incompetent to be able to complete a dialogue with devs This is an example, and IMO discredits most of anything else you may be trying to say.

Sadly, it is experiential, both personal and observed in environment. Business people of today are great at monologues. Of course, management experience is different, and would hide the fact of hitting the wall as success.

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

#193
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?

Absolutely.

https://www.zentao.pm/share/treeswingpm-97.html captures the reality very, very well.

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

#194
post #80

Earlier quoted context omitted.

> creative. Be creative on your own time. Lead a civic group. Be a good parent. Volunteer at a charity. If your main gripe at work is that you're on the value-adding side of a company, which is what feature dev is in software, you have it pretty good in this world. I don’t think this is a good solution. It is certainly “A” solution, and one that many folks pick. Software Development is ALL about creativity. It’s real…

Until you come to the realization that most developers are “dark matter developers” doing yet another software as a service CRUD app or bespoke app that will never see the light of day outside of the company. At the end of the day, if you got hit by a bus, your company would send flowers to your funeral and have an open req for your position before your body was buried.

That's a pretty cold way of looking at it. I've certainly never worked anywhere where the death of a coworker would be as inconsequential as you make it sound.

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

#195

Earlier quoted context omitted.

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

Ultimately, we might be running into the issue that the impact is spread over time and cannot be condensed into a single ROI number ?

Impact is spread over time and multiple vectors. So now you have three problems in addition to getting working code the door - prioritising proposed features based on estimates of value, finding accurate metrics for assessing value after release, and mapping value changes over time.

The nice thing about feature-driven-development is that it avoids the hard work of having to understand what you're actually doing.

You can make the hamster wheel spin really fast and persuade yourself you're really going places.

Until the wheel falls off.

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

#196

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.

If “burning a hole in my pocket” psychology is a struggle for you, a better banking overview screen will not set you free, but YNAB will:

https://www.youneedabudget.com/

(Not affiliated, just a happy customer that finally broke decades of bad financial habits due to this app and its attendant personal finance philosophy.)

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

#197
post #93
post #10

I don't actually understand what's bad about this, maybe someone who is in a company like this can explain why it's a negative? I am working with a company that is moving more towards this approach and I'm really enjoying it. Isn't this essentially what Basecamp's Shape Up method advocates for? Not everyone feels they need to be building something that changes the world I suppose. Each to their own.

This is about making teams completely responsible for the product as you possibly can. Maybe even profit/loss responsibility. The idea being they're closer to product then anyone, and thus should make better decisions. If you follow the feature factory route, the team will just produce things they are told too. If it doesn't work, it's not the teams responsibility. They did what they were told to.

Otoh, those who “tell” are closer to the business/client, and thus should issue better requirements. I honestly can’t see what’s wrong with doing what you’re told to. You cannot play a jack of all trades and program the damn thing perfectly at the same time. (And if you can, you should not waste your time bringing profits to that Corporate, Inc anyway.)

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

#198

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…

Yes, reading the article is depressing because very very few companies have non-clown-driven product development.

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

#199

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…

Fortunately, the author wrote a great many other articles that go far further. It seems to me like the article is fine for what it is, it's just calling out a problematic pattern that commonly exists. It doesn't pretend to prescribe that to fix this pattern you need to do the opposite of every one of his bullet points. He instead writes lots of other articles dealing with the nuances of how to do better.

But it also sounds that you're worried about engineers constantly challenging product manager's decisions? I don't think that's the implied end state. Engineers don't see all the input to PM's decisions, and yes it would be more comfortable for the PMs if the engineers just trusted them to get it right all the time. But we (I'm an engineer) aren't dumb. We know nobody gets it right all the time, and we don't expect you to. But if we never learn which things worked out and which didn't, and some of the why, then what you're asking for is faith, not trust.

You don't need to include engineering in the decision making (at least, not more than you need for feasibility and cost estimates.) You do need to include engineering in the feedback loop, because we're not dumb monkeys whose only value is in realizing your vision. We know more about what's possible, and how to overcome some types of challenges with relatively little effort compared to the cannon that you'd need to (ask us to) build.

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

#200

Earlier quoted context omitted.

Until you come to the realization that most developers are “dark matter developers” doing yet another software as a service CRUD app or bespoke app that will never see the light of day outside of the company. At the end of the day, if you got hit by a bus, your company would send flowers to your funeral and have an open req for your position before your body was buried.

That's a pretty cold way of looking at it. I've certainly never worked anywhere where the death of a coworker would be as inconsequential as you make it sound.

I’ve only worked at one large company in my life - at the time it was a Fortune 10 non tech company. I didn’t have a name in any official sign on or documentation. I had an “SSO number”. My 2nd level manager wouldn’t have known me if he bumped into me in the street.

I worked at a startup where the founder thought he was irreplaceable since he was the only one who knew how to modify and compile the custom C/MFC custom IDE/VM/compiler that he developed and everyone in the company had been using for years before I got there.

They somehow convinced him to show me how everything worked since I was the only person who had a C++/MFC low level optimization background. As soon as they were comfortable that I could do it, the board pushed him out, laid off a bunch of other developers and gave me the responsibility.

His name was never mentioned again.

Post reply on HN