91–100 of 286 posts
What's wrong with feature factory ? If you're delivering something good for clients.. No measurement / Success theater / core metrics This takes time and mental space. That you could better use to... crank a new feature! :)
> If you're delivering something good for clients... That's the crux of it, isn't it? How do you know that what you're delivering is any good?
Earlier quoted context omitted.
If you know it is going to be a nightmare to support, it will consume tons of resources (cpu/storage), and nobody wants to pay for it (or not pay enough to cover its costs), it is not good. As has been mentioned many times on this site, it is very easy to sell $2 for $1 all day long.
> nobody wants to pay for it (or not pay enough to cover its costs), it is not good. And how do you know this in advance?
‘Will you pay an additional $x/mo for this feature?’
You can estimate your AWS costs for what the feature would cost for that user.
You can estimate dev and implementation time.
It doesn’t even have to be 100% accurate, but if the numbers come nowhere close to making sense, don’t pursue this further.
Now, there may be a future time where some fundamental cost changes, and it is worth considering again.
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.
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.
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…
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).
That's how you end up with: https://gcemetery.co/
Very good article, so good that my coauthor and I used the metaphor in our book.
Earlier quoted context omitted.
I strongly disagree with this sentiment. I’ve seen quite a few features added simply ‘because we can’, without any thought to ongoing maintenance, support, or additional infrastructure requirements/costs. A little bit of common sense and forethought can go a long way in preventing unprofitable or revenue-decreasing features from being added to the product. If you keep adding features, without increasing your conversi…
You are basing your sentiment on assumptions that cannot be verified in practice without implementing/releasing the features. Nobody wants to implement revenue-decreasing feature but nobody knows beforehand whether they will increase or decrease revenue. So such statements are useless.
Approximate costs can be estimated before hand.
You can even ask the customer if they are willing to pay a specific amount for the feature.
But, insisting you have to build and deploy a feature first, before you have any idea of its impact, that is, an expensive, and foolish way to learn.
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…
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 improving, or even maintaining the core product, then you’re probably doing more damage than good, and neither the developers nor the customers will thank you for it in the long run.
In this framing, a factory is supposed to be bad? Aren’t factories efficient and the best way of producing things at scale?
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…
Now, you will have other priorities. Make sure you aren't dropping them. But most things are communication based. In time, you will find ways to improve without disrupting. Backwards and forwards compatibility will be tools, not burdens. Stability of the core will similarly work for you, such that you may start choosing to leave parts alone as you focus on peripheral changes that will have clearer impact to users.
The stability part is hard to overstate. There is a reason the Arduino uno is relatively unchanged. There is massive value in having a stationary target for what you are building. Custom everything down the line is an easy recipe for failure. Even if there are improvements that can be made down that line.
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…
This has been my experience at every startup I've worked in before we found product market fit. Like you, I don't see the state this article describes as a bad thing. Sometimes, that's what it takes to survive.