[smnscu]

Can't a CI/CD pipeline + various processes be good enough to achieve a similar efficiency for under-100-engineers companies? Honest question - because I'm pretty sure I've heard some people claim similarly fast "idea to production" times.

[barrkel]

Usually, feature requests go through a product manager who can do analysis, integrate with road map, prioritize against other features, figure out if there's overlap with another feature (maybe one coming up soon) and so it shouldn't actually be implemented, etc.

There may be some communication between product and design to figure out how it should look and feel.

Then it'll go into a sprint most probably, but not the current sprint, because that would change the scope and affect estimates and possible delivery timelines. You'd only change the sprint scope if the team is running out of work to do or there's a major customer request or other panic.

There will be some measure of QA, ideally. Some people fly by the seat of their pants, and rely on fixing things in production if it breaks in production. This is using your customers as QA. Can work if you roll out gradually and are very responsive to any reports of regressions.

All in all, this is unlikely to happen in less than a couple of weeks. The processes are designed for predictable, consistent delivery and to minimize surprise. Shortening the chain will mean less integrated decision making and will increase the amount of surprise and inconsistency in the product and its delivery.

[sophistication]

The processes are also designed such that people do not feel overstepped and ignored. After all, most things in life are about social status, or more immediately about salary status and job position.

If someone secretly implements an awesome feature, others might be envious as it does not seem deserved if their idea did not receive the same level of scrutiny by the usual processes as other decisions did.

Theoretically, it probably won't cause much chaos at all if programmers are allowed to add small GUI tweaks and the product likely benefits from it.

The degree to which this would work probably depends a lot on the extent to which the programmers have reached Kegan level 5, so practically it probably won't work all that well.

http://i.imgur.com/K4AVFbW.png

[sidlls]

It's pretty rare for someone to secretly implement an awesome feature. Usually the way that works is as you hint at: someone who already has high social status in the organization gets a lot of leeway to do his own thing while everyone else is constrained to the usual process.

The envy isn't about the awesome feature: it's about the fact that this developer gets even more attention and positive notice from leadership by means that aren't available to other workers due to social status (rather than merit).

[tcmb]

To add to this good answer: in many cases you also don't want to overwhelm the users with frequent, unexpected changes, especially in 'enterprise' software.

This is not so much a problem when you add a new feature like this triple-click which doesn't change existing usage and workflows. But even here you want to add that to your documentation, inform your support staff about it etc.

For changes that affect the look & feel of the product, your users will curse you if you roll out multiple of those per week, even if everything is totally stable and free of bugs.

[markatkinson]

Not so sure. One developer understands his whole code base and environment quite well. So let's say an error occurs during build it's likely he will be able to check out the logs, navigate to that area of code and troubleshoot.

In a larger team the flow of info is DevOps/Developer spot error in CI/CD, find out which commit/Developer broke the build. Email/slack/ walk over to let them know and sit down for a friendly troubleshooting session.

Resolve the problem. Follow necessary processes to commit change. CI/CD hosted agent is busy building other projects because not enough budget for multiple hosted agents and all CI/CD is handled in the cloud. Time to go home!

Obviously that was a bit facetious but you get the picture.

[slivym]

Can you imagine running a company with a product where 100 people feel empowered to make small tweaks to the UI without going through a prioritization and design process?

[sidlls]

Sounds like a nightmare to me. Probably most of those developers secretly think they work with incompetents.

[jatsign]

Our team requires code review, and often times the comments are non-trivial. I think feature A could be implemented this way, a teammate thinks it should be done a different way. Neither way is wrong, but it requires either the team come to consensus (takes time) or the team lead makes a call (and potentially ticks someone off).

Additionally, beyond trivial projects, some changes may require changes to architecture, even small ones. A new feature may require a new index, a schema get updated, a new worker be setup to run in prod, etc.

And usually there are multiple PRs waiting to be added, which have to be deconflicted, and the lead dev still wants to code so everything takes longer than you'd think.

[test1235]

I reckon it's more of a question of bureaucracy than technology. If I were to do something like that on the project I work on, I'd need at least four other people involved, and a stack of meetings to get the feature approved for development.

[badpun]

Just a CI/CD run can easily take an hour or two. Add the code review back-and-forth (mostly waiting for reviewers, but also waiting for CI after every iteration) and a change that you could do solo within a two hours will take a couple days when working on a team. I've yet to see it go faster than that.

[bigbluedots]

Yes, but most of the time a new feature request will be in a backlog behind many other things, at least in most places I've worked

[jasonlotito]

> Can't a CI/CD pipeline

Those 100 engineers have to first agree on a CI/CD pipeline.