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

271–280 of 286 posts

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

#271

Post by rileymat2 »

notyourday wrote: post #265
rileymat2 wrote: post #248

Earlier quoted context omitted.

> in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X This is misleading, you should not be refactoring some other random code. You should be refactoring the code you are adding to/changing as part of the work. And it should be in proportion to the size of the change.

Who established the process control? The same developer that does the refactoring? Because if it is done by someone above him on the org chart then the developer has to either lie about what he is doing or he has to break it down into the refactoring + feature.

If you were to take a tdd style micro loop of red/green/refactor it is part of the feature. There is no untangling no separate estimation.

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

#272

Post by 0xff00ffee »

sfink wrote: post #215
0xff00ffee wrote: post #131

I've had to make the decision to steer my design resources into "feature factories" because my customers are sometimes fickle. There are a number of instances where features were paid for, developed, and then not deployed. It hasn't become discouraging yet because there has been professional growth in developing methods for constructing and deploying said features, but I am concerned as to our financial ability to id…

I dunno, if I were an engineer in an environment like that I'd be fine with it if (1) you were up-front about this being a necessary hack to sustain the company for a bit longer, and (2) there is a vision and a process to refine that vision of where you would all like the product to go. (2) is so that these seemingly short-term features could either be seen as prototypes or first cuts at the future you'd really like…

Thanks for the feedback. That's pretty much how the discussions go. The team is small so I can still be 1:1 with them, and be direct about the state of things.

>This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests.

Yeah, this is a really good indicator. Heck, if this keeps up -I- won't want to do it anymore! Which I think is perfectly natural.

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

#273

Post by dennisgorelik »

cgriswald wrote: post #68
Alex3917 wrote: post #25

Earlier quoted context omitted.

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…

> Those specific users won't use it anyway even if you add it I think people read this and think, "Why bother, then?" As someone who is often this user, I don't end up using your product because I've already moved onto a competing product or service; or because I never hear that you have added the feature. Whether your metrics move after adding the feature might be a matter of timing. There's also the chance I will c…

> competitor starts ... showing a real lack of professionalism

Betting on eventual competitor's incompetence in the future - is not a reliable strategy.

In such situation it may be better to implement that feature only when entrenched competitor with that feature will start pushing their customers away.

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

#274

Post by s_y_n_t_a_x »

_y5hn wrote: post #181
s_y_n_t_a_x wrote: post #94

Earlier quoted context omitted.

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

No that's not the point. The point of agile development is not to get stuck in the water with long releases and no feedback cycle. It doesn't mean you blindly follow customer feedback and guesses until something works. It means you incrementally release your vision.

tldr: agile tells you how to release, not what to release

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

#275

Post by s_y_n_t_a_x »

sfink wrote: post #204
s_y_n_t_a_x wrote: post #62

Earlier quoted context omitted.

> Why would anyone build features without any thoughts about their benefit? > In practice you never know how a feature is going to work out Those two sentences are somewhat contradictory. If you think through the features you should know exactly how they further your initial goal. When you add things based on what some people might like, that's when you are guessing and you can't know. This all boils down to having o…

Vision is good, but any product decision is still a guess about what will further your goals. Guesses can be right or wrong -- or if they are never wrong, then you're not doing anything that every other competitor in that space won't already be doing too. (And in that case, why have product management at all? Fire them and hire more engineers so you can follow the taillights faster.)

There's a difference from a blind guess and an educated guess.

And honestly yes, you shouldn't have product management. Projects should be coordinated by product leads and their engineers. The only people that can plan a vision for software are the people who make it. You're paying these engineers for their knowledge, use it in all capacities.

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

#276

Post by pm90 »

tonyedgecombe wrote: post #264
pm90 wrote: post #147

Earlier quoted context omitted.

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

Which is exactly why it's best to maintain an emotional distance. If you are looking for it to be fulfilling then in most cases you are going to be disappointed. Almost by definition there will be little or no intrinsic rewards, the extrinsic ones will drive that out.

> Which is exactly why it's best to maintain an emotional distance. If you are looking for it to be fulfilling then in most cases you are going to be disappointed.

I do see your point but the difference is that in my perspective the emotional attachment to something I build lasts only as long as I'm building it. Once the thing is delivered, its up to the users to ultimately decide to use it or discard it. I think my emotional attachment is to the process of building things rather than to the thing produced by the process.

I do agree that if you want to see the thing you built get used then yes, very bad idea to get attached to that emotionally. But the way I see it, after its built its out of my hands.

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

#277

Post by btilly »

plinkplonk wrote: post #245
btilly wrote: post #207

Earlier quoted context omitted.

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 is impossible to verify with as little context as you have given whether this is a good or a bad thing. But it clearly has a lot of bad in it. In the case of an "enterprise software project", the sales process is…

"An example of an alternative that is appropriate for a lot of web companies (for example Google, Amazon and Booking) is an A/B test culture. Release features as A/B tests with transparent metrics. Share the metrics with everyone who is part of the decision INCLUDING devs. Proceed with general rollout of the features that actually produce positive results and rollback of the ones that don't." If this is the process G…

This is a process that some of Google followed as of 10 years ago. I cannot tell you whether internal pressures have caused groups to not follow it or they are measuring the wrong thing.

I know from experience that A/B testing can make it hard to have a coherent product design (Amazon's page is a good example of that). But it is still much, much better than the usual alternative.

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

#278

Post by mikulabc »

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…

I think if we look at Excel, we see that additional features were welcomed and it became very big, same with Word, but then we look at today's google docs and spreadsheet from google and wonder where all that stuff went, but we adapt and now i am fine with simplicity

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

#279

Post by _y5hn »

s_y_n_t_a_x wrote: post #274
_y5hn wrote: post #181

Earlier quoted context omitted.

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

No that's not the point. The point of agile development is not to get stuck in the water with long releases and no feedback cycle. It doesn't mean you blindly follow customer feedback and guesses until something works. It means you incrementally release your vision. tldr: agile tells you how to release, not what to release

Agile Manifesto and IT industry is based on customer vision only. If you are startup CEO, you are customer of the programmers, ie. the one who pays the bills!

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

#280

Post by ehnto »

BlueTemplar wrote: post #262
TeMPOraL wrote: post #158

Earlier quoted context omitted.

That depends on who the clients are, and why did they hire you. If you're just a subcontractor in an org run by smart people, it may very well be that they're asking for X, actually need X and expect to get X - they just outsourced the boring work to you.

I'm not sure how smart those managers are - I would assume that the best programmers would steer clear of jobs like these ?

Why would you think that? The project manager has communicated well with the client and the requirements getting passed along are correct and full. The developers are specialists in their platform, so implementing the feature is no problem.

From experience, it's actually a really nice environment to work in. Everyone is good at their job and you don't have to deal with the clients directly.

Post reply on HN