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

181–190 of 286 posts

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

#181

Post by _y5hn »

s_y_n_t_a_x wrote: post #94
lazyjones wrote: post #83

Earlier quoted context omitted.

Google certainly had visions for all their products. They just didn't work out, for reasons that became apparent much later (although some people will always claim they "knew" beforehand).

Those visions are not long term goals. They are spin-offs that have nothing to do with anything. That's how you end up with: https://gcemetery.co/

That's the whole point of agility: Release working software often. Make new business decisions based on customer feedback. Remember Google Beta? Not saying it doesn't offload responsibility and potential damage to end users..

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

#182

Post by titanomachy »

I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint.

I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work and didn't spend any time on the Kafkaesque exercise of "sprint retrospectives" and "grooming sessions". Our product manager didn't tell us what to build, but acted more as an advisor for the engineering team leads.

I think in some case scrum is an attempt to compensate for inexperienced management.

I assume we just weren't "doing agile", but when I was younger it always left me feeling vaguely inadequate: if I was just more efficient and competent, maybe the 2-week sprint would fit better. Maybe that was the point.

Has anyone here ever delivered useful features to users on that kind of cadence? What was it like?

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

#183

Post by _y5hn »

UK-Al05 wrote: post #93
davzie wrote: 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.

This is pinnacle of old style dev. It just doesn't make much sense unless devs become stakeholders.

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

#184

Post by tomnipotent »

notyourday wrote: post #153
tomnipotent wrote: post #148

Earlier quoted context omitted.

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.

> That these companies don't treat engineers as a cost structure the way you were talking about. That's absurd. The reason those companies are making money is because they are costing every single thing. That's the reason why tech gets a seat at the table -- it is a cost and its top of the line managers understand that this is a liability and drive that understanding through the entire tech organization.

> The reason those companies are making money is because they are costing every single thing

Terribly untrue. This is fundamentally what makes them "technology" companies, because of how engineering expenses are treated on the P&L and the say it has at the C-level.

There's a fundamental different between how things roll-up n your 3 sheets, vs. how your company internalizes those numbers and acts upon them.

You've made a lot of broad generalizations without backing anything up with specific examples. It's difficult to have a conversation with theoreticals and ideas.

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

#186

Post by pseudalopex »

PragmaticPulp wrote: post #141
alexandercrohde wrote: post #78

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…

Organizations where individual contributors are respected find ways to communicate what's discussed in those meetings. I wouldn't want to be a manager in an organization where engineers can assume those meetings aren't taking place.

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

#187

Post by Super_Jambo »

bob33212 wrote: post #136
userium wrote: post #129

Earlier quoted context omitted.

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

In my experience people are afraid to ask that question. The answer to that question may lead to questions around total addressable market which could cause uppermanagement to question the viability of the product or at least the cost / benefit of having a big development and product management team in the first place.

This is a terribly sad comment on the structure of our society, people worried they might be making something pointless. And the solution is to make sure the people paying for it don't realize.

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

#188

Post by ebrewste »

titanomachy wrote: post #182

I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint. I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work…

When I was doing full stack, solo development, I could get features with real customer value delivered in <= 2 weeks. The flexibility afforded when doing solo development in an area you are competent can unleash some great velocity, but has pretty predictable downsides (can't scale past what you can do yourself, when the project gets big enough, the context switching is a killer, etc.). I don't think I personally have ever hit this level of personal development velocity when working in a group bigger than two people.

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

#189

Post by anonsivalley652 »

titanomachy wrote: post #182

I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint. I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work…

Yep. Agile theater often happens when whoever wears (or doesn't) the PM "hat" doesn't have a clue beyond their so-called certifications and amateur "expert" non-experience because they're afraid of appearing incompetent. Then, it reverts to: Big Design Upfront -> Big Deliverables at the End -> sad, expensive fail.

Agile means:

- Build-test-feedback-adjust loop is as tight as possible... hours or less to get a fix or a quick feature.

- The end-users are involve from the beginning to constantly get what they really need (capture good requirements, not necessarily what they ask for directly) and feedback to make usability/feature improvements.

- Someone is prioritizing fixes and features from what users need right now to do something useful, rather than arbitrarily shotgunning features in milestones.

- Just enough intra-sprint time is dedicated to test improvements, bug hunting and refactoring.

- Using continuous integration (CI) and/or continuous deployment (CD).

- You are what you measure and post publicly. A giant dashboard in the office to show key metrics like open tickets, who's working on what, app load, app latency, shopping carts/sales, current scaled-infrastructure costs, etc.

- Minimum ad-hoc meetings and very few scheduled all-hands.

- Let developers focus on one or two tasks rather than constantly interrupting them. Some sort of office GTD system combined with industrial andon light towers to signal: serious concentrating, light work, need to socialize, or not in.

- Unless you're building an elevator, fission reactor or an intersellar space ship, be against waterfall development.

I'm forgetting a million other things like mindset and differences in processes, but the above is a rough sketch.

I do this all the time: It's too easy and too comfortable to get wrapped-up in technologies, methodologies or building out elaborate processes and bussiness-y minutia, which I think is a procrastination / ego defense-mechanism because of a core fear of many people of rejection from the user(s). It's so very easy to build something for yourself, but emotionally more difficult to build things others will see differently.

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

#190

Post by tirrellp »

titanomachy wrote: post #182

I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint. I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work…

The point of Scrum is not to deliver a full feature in a 2-week timebox. Its to deliver 'something of value' in a 2-week timebox. 'Something of value' could be stuff like: - A tracer bullet implementation of a new DB technology to de-risk full implementation - A skeleton workflow so you can validate with stakeholders that you're on the right track in terms of understanding how they work - A completely failed attempt at an implementation of a particular feature as to outline key lessons, go forward plan, and the next set of experiments you want to run to mitigate technology risk (will this work), customer risk (will they like it), or product risk (will it sell)
Post reply on HN