Ask HN: Why is your company slow to ship features?

4 点作者 erlich大约 2 年前

There are a lot of apps out there that seem so stagnated in terms of shipping product features. Even obvious and easy stuff. And for apps that you look at them and think: there really isn't all that much functionality here.It makes me think there is something fundamentally wrong with the way we write software.

7 条评论

ian0大约 2 年前

At its core, the "shipping stuff" loop is pretty simple - understand your users problems and ship a feature they love.You can imagine the fastest implementation of the loop is a single dev who knows their customers inside out and talks to them every day, has a flair for product design and works on a youthful and well architected code-base in a language they know extremely well.In real life speed and quality of the loop are slowed down by:1. The complexity of your organisations. Even in small companies once the engineer is out of earshot of the customer you rely on "Chinese Whispers" in the form of management, sales, product management, UI/UX, design guys etc. Its not due to incompetence, its just a very hard organisational problem whose solution depends on your company & market.2. The existing complexity of your product. Products & underlying systems can be architected badly. This can make even trivial things difficult. It could be because of a lack of design knowledge (symptom: too many unused features), lack of systems knowledge (symptom: changing the colour on a website takes a day) or just a complex domain (eg tax accounting, financial services, crms etc)I think you can trace back most other things (picking the wrong frameworks/languages, badly designed features, poor reliability, time taken with overhead like scrum & needless documentation etc) from the above two.

bruce511大约 2 年前

"slow" is on the eye of the beholder :). Maybe a week is slow for some, maybe a year is slow for others.I can say this though, adding features comes at a cost. Not the programmer-cost of the feature though, all the other costs;A) documentation. If it isn't documented, it doesn't exist. Good docs takes time and effort (and skill).B) UI clutter. Most features require at least some UI to be added to the program. Menu item, check box, whatever. So 100 features later you have 100 little UI things, and it's starting to feel cluttered.C) utility versus long-term maintainence. Add one more report, which only a tiny number of customers asked for (and none of them will actually use) and you will be updating that report _forever_. 100 reports like this later, and there's a lot of overhead.D) training. Existing users will see this new UI. They need to be trained on it. Who's doing that? When?E) overkill - simple programs appeal to people with simple needs. If Wordpad will do, the Word is overkill. Sometimes adding features means you're now targeting a different market, at a different price point.F) security. Sure we can add JavaScript support. Not sure that's a good idea though. Features need to be thought-through from a security perspective.G) price versus return. Sure it costs money to add this (plus all the above) - who's paying for that?I could go on (translations, compatibility, partner products etc) but you get the picture...

leros大约 2 年前

As we've gotten larger, we've gotten slower in many ways. I think they're valid for the business but its frustrating as an individual.We now have to run changes through legal to ensure global compliance as we're large enough to be a lawsuit target, especially in the EU where they're looking for US companies to make examples out of.We have to run things through brand marketing and shared design teams to ensure we're acting as a consistent company despite actually being hundreds of teams. In fact, several years ago, we had a multi-year long initiative to introduce a single UI library across the company - before we had different UI design in different areas of our product.One thing I find debatable is all the communication that takes several weeks or months before we can do anything. Getting all the stakeholders across different parts of the orgs together, incorporating their feedback, following up, etc. I think we could be nimbler in that regard and maybe some teams are.There is of course added overhead of large engineering teams on older codebases, so development velocity slows but that feels more inevitable to me.

logicalmonster大约 2 年前

I'd say that general office politics and bureaucratic friction is a big one in the industry.Project Managers can be hunting for quick wins to protect their own jobs, so they lead developers down stupid feature paths for the appearance of productivity rather than focusing on the great feature the company really needs, but that requires some focused work.Managers are bad at assessing productivity, so they adopt bad processes (constant scrum meetings and the like) that can be draining towards motivation, purely to have some way to track people. And even when managers try and come up with some objective methods of measuring productivity, they're usually stupid ones; think of counting lines of code as an example.Hiring enough employees is a big minefield. Managers are protecting their budgets and roles in an organization. What should become a relatively quick and simple process (have one technical leader pick a few promising resumes out of a pile, then have your devs talk to and pick the smartest people) can morph into an 18 step ordeal with lots of slow communication between half a dozen committees.

majestic5762大约 2 年前

Unfit team, unfit org processes, unfit infrastructure, unfit codebase, unfit business model. They don't start happening all at once, but it takes just one of these to corrupt the others in time. Theoretically a good team could have the power to throw everything away and start from scratch, but very few teams can be proud of such feat. Without the right people, incentives, mindset it's almost impossible, because no one has the guts and energy to take responsibility if there is no hope ahead. And passion, it's so important, but very few teams are proud of having passionate people, regardless of age

alxmng大约 2 年前

Overengineering. There are many unnecessary layers of abstraction that serve no material, quantifiable problem, but satisfy someone's arbitrary notion of clean code or best practices. This results in new features taking longer to develop because more code has to be written, and there's more layers to work with when writing new code.

评论 #35243543 未加载

tkiolp4大约 2 年前

Why do you think companies should be delivering features fast? What matters is quality.

评论 #35248518 未加载

评论 #35239388 未加载