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

121–130 of 286 posts

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

#121

Post by mokus »

mLuby wrote: post #102
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…

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.

being (sustainably) fast and producing quality code often go hand in hand. If management doesn’t know Cowboy Chris generates most of the debugging time, that’s a management problem.

A good management team is aware of which people are fast in short sprints but end up tangling things up on longer efforts, which people take time to build steam but never hit that slow-down, and which people fit other patterns (for example, the extremely rare fixers who can take Cowboy Chris’s shit and funnel it into something useful, or the even rarer speed demons who can sprint like that forever because they are like Chris but they work cleanly too)

Good engineers, given the chance, will find and stick with those managers too.

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

#123

Post by BlueTemplar »

ehnto wrote: post #113
hedora wrote: post #97

Earlier quoted context omitted.

The article is describing a broken process that is often installed as organizations scale. If this matches what you’re currently installing, I suggest reconsidering your plans. Medium organizations do need more process than small ones, but not all processes are good. In particular, if you have a growing product, and the plan is to ship a ton of features without internal (to engineering) coordination, and without impr…

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?

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

#124

Post by dragonwriter »

While this focusses on places selling software (features added to close deals, etc.), it is probably an even more pervasive problem in internal IT shops—and a more tragic one, because internal IT organizations should be better positioned to tightly align on business value rather than sales, though this is often hampered by internal organizational structures which sometimes incentivize arms length, contracting-like interactions.

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

#125

Post by BlueTemplar »

Isamu wrote: post #106
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.

Yeah, also, about :

> Large batches. Without the mandate to experiment, features are delivered in single large batches instead of delivering incrementally. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers at the conclusion of each sprint

Lol, I've worked on "Waterfall" projects more agile than this...

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

#126

Post by ehnto »

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's often the case. If your agency is part of that discussion then you can provide enormous value to the client from your experience, and hopefully PMs are pulling the developer input up into discussions with clients as well. But then that is your relationship changing, and you can start to address many of the concerns in the article anyway.

I guess my point is just that there are certain relationships where it's just not your decision whether or not feature X is a good fit. I wouldn't want people reading this article thinking their company is broken, when it's just a different type of engagement.

Sometimes the CEO wants a popup on the homepage, and every single person in the chain between the CEO of the client company and the Developer at the agency agrees that it's a bad idea, but you still have to implement it.

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

#127

Post by tomnipotent »

notyourday wrote: post #117
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…

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

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

#128

Post by awinter-py »

> success theater

such a good phrase. premature 'mission accomplished' is always embarrassing even when you're just the one stuck cringing and golf clapping in the corner

Common thread here seems to be lack of argument / buy-in process. Central leaders need to (1) convince the team that tactics accomplish team goals and (2) have team goals. Bad teams do none of the above.

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

#129

Post by userium »

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…

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 factory? Something that I recommend for the teams I work with, and noticed that actually works, is "Hypothesis-Driven Development".

In short, replace the items in your product backlog with experiments rather than user stories. Instead of starting with a user story or epic, start with a testable hypothesis. Then run small experiments that will prove or disprove that hypothesis.

My favorite question nowadays is "Wait, why are we building this feature again?" :)

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

#130

Post by hamiltont »

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…

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 :-)
Post reply on HN