Live data from Hacker News

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

cutle.fish

171–180 of 286 posts

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

#171

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…

yes, refactoring is never something that I would plan as a standalone thing - it's just a part of building features or fixing bugs.

If you're going to be working on a part of the codebase that you know is difficult to work with, you need to pad your estimate whether you're planning to refactor it or not - either you use the time to do the refactor, or you use the time to sort out the bugs you introduced by working on scary code without refactoring.

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

#172

Earlier quoted context omitted.

> This is an endorsement for 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. The grass is always greener on the other side of the fence. The problem with cog in the machine analogies is that people only think of the plus sides of having more input in decision making processes. Wh…

> and accepting the blame when things go wrong, you can always move up into management. In most companies, accepting blame is career suicide. Most people who move up in management are good at taking credit for wins and pinning down someone else for failures, or moving on to different projects before their decisions come back to bite them. And that's the kind of management that leads to broken process that the OP ment…

Blame will make problems go underreported and responsibilities shunned. A healthy org will invite organic planning and distribute power while providing psychological safe space for real autonomy. The moment of blame or downward finger-pointing, all of this too easily gets lost.

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

#174

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.

Conversely, I'd consider an account overview without a balance to be useless. That's what an overview is for. shrug

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

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

Speak to management about contributing/licensing out to relevant Free Software/open source projects.

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

#176

Earlier quoted context omitted.

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…

Sounds like the point of your comment is "all this is correct but you people are too incompetent to actually evaluate these signs".

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

#177
post #67

Earlier quoted context omitted.

There are lots of bad actor reasons (putting career advancement ahead of product success), but there also structural issues that can lead teams to operate this way. The most common: product decisions are made higher up by well intentioned leaders who lack the product management expertise and the context the team does. Usually this looks something like a sales person hearing from a couple of customers “we really need…

I hear that these situations exist, yet this is the complete opposite of what I was taught, which is that (at least !) the project manager had to have frequent and direct contact with the customers starting from trying to figure out what their real needs are - for the project to have any hope to succeed?

In software/tech world, PM's customer are often internal stakeholders, often not all relevant ones. Very rarely company's customer. PM juggles internal issues like milestones, priority, resources, budgets and even some politics.

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

#178
post #159

Earlier quoted context omitted.

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

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.

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

#179

Earlier quoted context omitted.

These are all expected and desirable outcomes. Sometimes technical debt is not worth paying off until your hand is forced, like in these examples. A large part of management is making the implicit explicit, and communicating the outcome of these efforts. None of these examples have anything to do with refactoring code, specifically, and the challenges faced within that work.

The first sentence contradicts the other two and it contradicts the previous position where refactoring was done implicitly without anyone above in the org being aware of it.

See my last sentence. The OP listed examples of process failure, not refactoring.

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

#180

Earlier quoted context omitted.

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.

You're asking a bank to remove visible account balances from a dashboard view?

I think it’s a valid request. I wish Apple’s iMessage App would allow hiding or moving conversations to folders to remove from sight. I may have an emotional or upsetting text with someone that I don’t necessarily want to see every time I open the app, but also don’t want to delete it. Or may need to use my phone in a presentation etc, and not want to show certain messages.
Post reply on HN