To be honest I've never worked in an environment that seemed too complex. On my side my primary blocker is writing code. I have an unending list of features, protocols, experiments, etc. to implement, and so far the main limit was the time necessary to actually write the damn code.

▲

swatcoder 17 hours ago | parent | next [-]

That sounds like papier mache more than bridge building, forever pasting more code on as ideas and time permit without the foresight to engineer or architect towards some cohesive long-term vision.

Most software products built that way seem to move fast at first but become monstrous abominations over time. If those are the only places you keep finding yourself in, be careful!

▲

ebiester 15 hours ago | parent | next [-]

There are a wide number of small problems for which we do not need bridges.

As a stupid example, I hate the functionality that YouTube has to maintain playlists. However, I don't have the time to build something by hand. It turns out that the general case is hard, but the "for me" case is vibe codable. (Yes, I could code it myself. No, I'm not going to spend the time to do so.)

Or, using the Jira API to extract the statistics I need instead of spending a Thursday night away from the family or pushing out other work.

Or, any number of tools that are within my capabilities but not within my time budget. And there's more potential software that fits this bill than software that needs to be bridge-stable.

	▲	swatcoder 15 hours ago \| parent [-]
		Absolutely. But the person I replied to seemed to be talking about a task agenda for their professional work, not a todo list of bespoke little weekend hobby hacks that might be handy "around the house".

▲

17 hours ago | parent | prev [-]

[deleted]

▲

f1shy 18 hours ago | parent | prev | next [-]

I don’t want to imply this is your case, because of course I’ve no idea how you work. But I’ve seen way too often, the reason for so many separate features is:

A) as stated by parent comment, the ones doing req. mngmt. Are doing a poor job of abstracting the requirements, and what could be done as one feature suddenly turns in 25.

B) in a similar manner as A, all solutions imply writing more and more code, and never refactor and abstract parts away.

	▲	mckn1ght 18 hours ago \| parent \| next [-]
		My guess would be that the long list is maybe not self contained features (although still can be, I know I have more feature ideas than I can deliver in the next couple years myself), but behaviors or requirements of one or a handful of product feature areas. When you start getting down into the weeds, there can be tons and tons of little details around state maintenance, accessibility, edge cases, failure modes, alternate operation modes etc. That all combines to make lots of code that is highly interconnected, so you need to write even more code to test it. Sometimes much more than even the target implementations code.
	▲	17 hours ago \| parent \| prev [-]
		[deleted]

▲

iberator 17 hours ago | parent | prev | next [-]

Hehe. Try working for some telecoms dealing with gsm, umts, LTR and 5g.

	▲	fuzztester 17 hours ago \| parent [-]
		or banking. or finance. or manufacturing. or $other_enterprise_lob_area. souce: been there, done some of that.

▲

yoyohello13 11 hours ago | parent | prev [-]

Man I wish this was my job. I savor the days when I actually don’t have to do requirements gathering and can just code.