I don’t think that any of this captures what it means to be in a “feature factory” or, to use the term I prefer, a “ticket shop”.
You work in a ticket shop when the driver on what gets done, when, and on what timelines, is the business rather than engineering. Unfortunately, many companies probably have to be ticket shops. Low-margin businesses can’t afford to have half of engineering time spent on things that they perceive as unnecessary R&D. The truth is that there’s just more demand for IT ticket-shop development than for real engineering.
I’ve come to the conclusion that, rather than fighting the bifurcation and dumbing-down of software engineering, we should accept it and figure out how best to split the “programmer” job. Some people are fine working on tickets that come from the business, and some people want to grow as engineers and take on harder technical challenges and have multiplier-level effects. That’s not a bad thing. We just need to do a better job of mapping people to where their skills and desires would naturally put them.
Your first point does not match closely to my experiences at all.
Rather than argue, I’m going to share a few perspectives from teams I’ve been close to.
Sample phrase: “I’ve noticed a lot of ‘tech debt’ work going through; it’s really important we focus on our key commitment to deliver <feature>. If you’ve got anything outside the backlog, write it up and we can talk about it in the morning meeting”.
This kind of ‘control process’ rarely exists where the immediate pressures are communicated openly because managers and developers largely end up agreeing on what to work on.
Sample phrase: “We don’t want to micro-manage you; we trust our people.”
Failure mode: 1-2 developers are given a high level request (‘we have a new product starting with its own codebase; can you make it so existing users can log into it?’. Absent oversight or hard timelines, they make difficult architectural choices (“a separate app/db for SSO written in a safe language”) which cost a fortune.
A large (~60+ staff) web agency is running on thin margins but isn’t 100% clear where their money goes.
They hire a junior developer to help the non-programmer CTO integrate the finance system.
Weeks later, the finance system (which was never designed with an API) has a janky, unreliable integration which occasionally works. A 10 minute/week manual process is instituted to replace it. The project is shortly cancelled because the company is running out of money.
Team leader, at the start of a project:
Our customers have been screaming for us to fix this dataset - we have hundreds of open, years-old tickets from complaints. In the past every change has taken weeks, and there are some types of change we don’t have a way to do.
We’ve finally got a team and time to fix this once and for all - I’d like to start by identifying which problem to tackle first - taking weeks to deploy a change, having a difficult and error-prone method for making the change, or not knowing how to make certain changes.
Team lead calls a huddle: “I’ve just come out of a meeting with our steering committee. If I can’t show that we’re making good progress towards <automating layout for print publishing> by <having one of the layouts in our styleguide implemented> by <date a book using that layout is released> they aren’t going to keep funding the project. Can we do it?”
The number one failure mode I see for leadership is failing to communicate the business context to the development team.
Ticket shops are not ‘leaner’ or ‘more efficient’ - even in the short term. They are primarily common because they require very little skill to set up, and they feel like an obvious solution to problems that do crop up.
The implication that working on business projects doesn’t help one “grow as an engineer” is the opposite of my experience. More generally I find a lot of damage is done by programming practices recommended by academic non-practitioners (e.g. “gang of four” book), and the most valuable advice I’ve seen has come out of direct business experience (e.g. agile). Actually using something to make money is a great way to ensure that you do it in a way that’s actually effective; academia’s incentives make it all too easy for academic work to become unmoored from the actual goal of producing working software, since academics are not rewarded for that (whereas businesspeople have at least some hope of making more money in proportion to their production of working software).
What’s needed is a way to incentivise businesses to share the generally-valuable work they come up with. On the code level I’ve written the same frameworks for four or five different companies. On the (possibly more important) process level I’ve found the right and wrong way to do a lot of parts of development, and gotten process improvements adopted, but again it’s a case of starting anew at each new employer. To a certain extent consultancies are in a position to avoid this issue, but as with academics it’s all too easy for a consultant to get their incentives misaligned and end up detached from actually producing value.
You completely missed the point of the article. He’s is proposing that the cause of many businesses low margins is due to working on things that don’t matter because they only measure velocity and ticket counts and not business success. Instead of identifying what actually brings value to the business they prioritize shipping features, any features. This has the effect of separating the businesses success metrics from the software teams success metrics and then you end up with very low margins because you are spending money on things you don’t need.
Software really shouldn’t be a low margin business.
There’s only one sign that you’re in a feature factory. If the the pursuit of number of features outweighs the design of the software itself.
If you have an environment where business people who will come to you with the set-theoretic union of every possible end-user item possible, and then turn that into a timeline you’ll end up with an incoherent wreck whose only ‘feature’ is being rewritten every few years and cycling through engineers who end up breaking out of the cycle of suffering and quiting.