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

141–150 of 286 posts

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

#141

Post by PragmaticPulp »

alexandercrohde wrote: post #78
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…

I don't think the article is saying engineers need to have a meeting for each of these. I think you're entirely missing the point. It's simply saying that you measure before you build a feature [and again after]. Any good product owner will already have data to support their prioritizations (e.g. this bug affects 10% of users, this feature only applies to 2% of users)

> I don't think the article is saying engineers need to have a meeting for each of these.

I think you've missed the point of my comment.

As I said, the core principles of the article are not wrong. It's the framing of the article that causes problems.

When engineers and other ICs read this article, they tend to assume that these planning sessions, feedback loops, retrospectives, and other mechanisms aren't happening because they don't personally see them. That's why I pointed out that most engineers wouldn't be happy if they were pulled into every single planning, retrospective, and feedback meeting that the product managers are doing. I'm not saying they're bad, I'm just saying it's bad to assume you work in a terrible feature factory if you don't see every item on this checklist.

This goes both ways, of course. It would be silly for product managers to read an article entitled "12 Signs You're Working In A Code Factory" and then start second-guessing all of their engineers' decisions or assuming the engineers aren't implementing proper process behind the scenes. That type of article would generate outrage on HN, but engineers second-guessing product management is always well-received in an engineer-centric forum.

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

#142

Post by spectramax »

In this thread: When your whole life is based on assumptions of 98% of it is wrong, you're gonna defend yourself to the tooth. It is emotionally challenging and damaging to the ego.

Watch Jim Keller (designer of A4/A4 Apple chips, Ryzen processor, x86 spec co-author and a legendary chip designer) make this point better than I can [Video link copied at 1:22:34 marker]: https://youtu.be/Nb2tebYAaOA?t=4954

People would say that the author of this post is arrogant and want to reject the status-quo - But I would say the opposite, people who have vested interest in the status-quo because their reputation depends on it, their salary depends on it are the arrogant ones because they reject reality in favor of their own good.

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

#143

Post by kube-system »

Alex3917 wrote: post #25
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…

Most times when users say they won't use a product because it's missing a feature: - Those specific users won't use it anyway even if you add it - The problem they identified is a legitimate problem that was preventing other people from using it - Whether your metrics actually go up depends on where that feature was in the critical path of your funnel. All else being equal, fixing legitimate problems with your produc…

This situation is further complicated when you’re making enterprise software where the purchaser often isn’t a user and the majority of the users don’t have a say in the purchasing decision.

A smart purchaser will define their purchasing criteria based on the needs of their users, but in practice, I’ve found that some haven’t done an accurate job of determining their users needs, and/or inject their own agendas into the requirements.

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

#144

Post by dragonwriter »

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.

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

Maybe.

OTOH, not only can focussed refactoring make delivering the features it is associated with faster, but refactoring—delivery-focused or not—is a really good way tonbuild knowledge of and proficiency with a code base, so if you aren't doing huge quantities of non-germane refactoring, it can actually be a personal delivery-speed enhancer, as well as the benefits for the team.

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

#145

Post by undefined1 »

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…

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." They say "add more, add more!" There's an old saying that I love about design, it's about Japanese gardening actually, that "Your garden is not complete until there is nothing else that you can remove." I think a lot of designers think the opposite way - "What else can we add to the game to make it better?" -Will Wright

"People don’t know what they want until you show it to them.” -Steve Jobs

"Writers and people who had command of words were respected and feared as people who manipulated magic. In latter times I think that artists and writers have allowed themselves to be sold down the river. They have accepted the prevailing belief that art and writing are merely forms of entertainment. They’re not seen as transformative forces that can change a human being; that can change a society. They are seen as simple entertainment; things with which we can fill 20 minutes, half an hour, while we’re waiting to die.

It’s not the job of the artist to give the audience what the audience wants. If the audience knew what they needed, then they wouldn’t be the audience. They would be the artists. It is the job of artists to give the audience what they need." -Alan Moore

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

#146

Post by tomnipotent »

hamiltont wrote: post #130
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…

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 :-)

> Fundamentally it's a lack of trust IMO

Which is usually a failure of communication. The whole "just trust us" bit doesn't work, and it takes real work to build a rapport with your stakeholders to earn "blind" trust, which is what most people are really asking for when they say "just trust us". This almost never happens, unless people have been working with each other for many years.

> then nitpick that "well that's not needed"

First, ask questions. Find out why they're willing to put energy into this - most people are not wasteful when they push back on things (most). Maybe their boss is riding their ass, and it's CYA. Maybe they're just stating a preference, so I'll ask questions to make this explicit ("So you just prefer it this way? No data? No customer feedback? Your boss didn't ask?").

Second, socialize things early and often. Tell people weeks, months, quarters in advance about some technical debt you're eventually going to get around to paying off. This gives people time to vent, challenge things, or say they're stupid. Use this time to refine your story, and get better at telling it in a way that gets the least resistance (don't need support, just fewer detractors).

Sometimes that "socializing" is complaining about a shared frustration. "Ugh, System X gobbled up Sharon's purchase order again and she has to spend another two hours after working salvaging things. Really wish they'd let us spend time fixing this, but you know how it goes."

By the time I've scheduled a meeting with stakeholders to discuss something (especially something I know will be difficult for them to see value in), I make sure I've individually discussed it with everyone in the room. When they see less disagreement between each other, there's less negative energy to build off. There may not be any positive energy, but that's much easier to deal with.

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

#147

Post by pm90 »

scarface74 wrote: post #90
pm90 wrote: 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.

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

Which is exactly what I expect them to do. Its a business and not a family. They compensated me for my work, I don't expect them to cry for me when I'm gone, but to hire someone immediately to continue the business.

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

#148

Post by tomnipotent »

notyourday wrote: post #135
tomnipotent wrote: post #127

Earlier 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?

That these companies don't treat engineers as a cost structure the way you were talking about. This creates a drastically different culture since tech has a seat at the table, and the CFO can't just willy-nilly makes demands that impact the entire engineering organization without consent. It makes a big difference.

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

#149

Post by bob33212 »

lr4444lr wrote: post #36

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

Sure. Someone is installing blinkers at the BMW factory which may never be used. There are plenty of jobs where you could say that the work being done isn't fulfilling because it is a waste of time. The problem is that at the BMW factory you know exactly what you signed up for when you became a blinker installer. At some software companies you are told that you are going to be part of a team that is building a successful product, then when you get there you see that everyone is running around trying to make features by certain dates for no good reason.
Post reply on HN