Signs you’re working in a feature factory (2016) • Hacker News Board

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

#111

Post by tomnipotent » Sat, Feb 15, 2020, 6:47 PM UTC

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.

I am "management", whatever that means. Sounds like you're pretty jaded about an experience you had.

Not all advice works for all people in all situations, but this has proven great for me.

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

#112

Post by _drimzy » Sat, Feb 15, 2020, 6:50 PM UTC

PragmaticPulp wrote: post #84

braindongle wrote: post #73

Earlier quoted context omitted.

Disagree. This is an endorsement of 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. Surely it's often case that life has people in this sort of scenario and there is no realistic way to a new path. In that case, sure, take care of your loved ones and yourself, stay put, and make…

> 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 mentioned in the article.

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

#113

Post by ehnto » Sat, Feb 15, 2020, 6:52 PM UTC

hedora wrote: post #97

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…

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 most of the discussions about business value, metrics and forward planning internally.

It doesn't have to mean that you have a business with bad processes, it could just mean you have the latter client relationship and a fairly mature process of delivery that doesn't require constant turmoil, refactoring and retrospectives.

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

#114

Post by vsareto » Sat, Feb 15, 2020, 6:56 PM UTC

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…

You'd better be paying those devs the cost of doing everything

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

#115

Post by ldng » Sat, Feb 15, 2020, 7:02 PM UTC

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…

My experience is that implicity is a huge problem as it's too often taken for granted and precisely not valued. Only when you stop doing people realize that since Jeff is on long leave server aren't updated and we've been hacked or that Lucy quited and everything seem to crawl to a halt because she implicitly was doing housekeeping on the database. It might not have failed you yet but be sure the day it does there a good chance it will be spectacular.

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

#116

Post by mokus » Sat, Feb 15, 2020, 7:03 PM UTC

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…

I do work on embedded systems and it works there too. Much better in any kind of project though is if you can get a management team that actually sees the value in it.

I still consider it pretty much mandatory to build core system improvement into feature estimates but by being more explicit and interactive about it you can get good feedback to refine your own estimates of what parts are even worth improving. It may be that the product line that uses the subsystem you want to improve is about to go a new direction, for example, and the better thing to do is to start preparing for that subsystem to go away.

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

#117

Post by notyourday » Sat, Feb 15, 2020, 7:09 PM UTC

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…

> 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 business. Every single code base that shipped contains warts that became obvious as soon as the final commit was one, which means that refactoring is a cost and costs need to be accounted for and prioritized according to business objectives ( which at the end is making money -- the money that pays developers salaries ).

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

#118

Post by BlueTemplar » Sat, Feb 15, 2020, 7:09 PM UTC

0x445442 wrote: post #109

sidlls wrote: post #88

Earlier quoted context omitted.

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

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

#119

Post by jiofih » Sat, Feb 15, 2020, 7:09 PM UTC

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…

That’s funny. I work at a billion-dollar corp and agree with almost everything said in this article. This is not about “devs doing everything”, but about not replacing your value stream with busywork and misguided delivery metrics. It’s very much on point.

I cannot imagine someone willingly adopting “no metrics”, “shiny objects”, “no retrospectives”, waterfall isolated processes, etc. so you must be just exaggerating? what exactly are your new efforts like?

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

#120

Post by funfunfunction » Sat, Feb 15, 2020, 7:10 PM UTC

borski wrote: post #71

funfunfunction wrote: post #35

Feature addiction is exacerbated by VC. Without real consequences to a poorly planned product roadmap due to the years of runway afforded by massive funding rounds, entire orgs fall into the “one more feature” cycle and never focus enough on measuring success in terms of real dollars. No one knows what went wrong when all the money is gone and devs/designers/PMs rinse and repeat at a new well-funded startup.

This actually isn’t true. VCs don’t want companies to build features, they want companies to listen to users maniacally and find product-market fit, then focus on growth (and/or revenue) like mad. That companies focus on features is a management issue and a sign of a failing company, not a sign that VC is somehow bad.

I agree that the issue is a problem of management. Though without oodles of cash to wash away missteps, poor management would be much more obvious. The ability to distill user feedback into the minimum number of valuable feature enhancements is what sets successful product orgs apart from failed ones. When cash is largely not a constraint, the tendency is to build exactly what each customer has said they want rather than try to come up with succinct improvements. The result is often bulky products that cost a fortune to maintain and only appeal to small number of customers.

VC is good if used correctly. But dumping wads of cash into a company to develop a product that isn’t capital intensive (like web or mobile tech) has the tendency to create bloated product orgs which optimize for the wrong things.