When I started at Apple in 1995 the way things got done was: you worked with a team that focused on, for example, the graphics frameworks of the OS. One engineer was tech-lead. They went to SIGGRAPH, tried to have their finger on the pulse of the "industry" and, of course, what our users wanted ... in terms of graphics on the platform.
So a new OS meant an opportunity to add some of these desired features to our frameworks. Tech-lead generally called the shots, chose various engineers on the team to own various parts. And so we coded.
And maybe I am getting a bit off topic here, describing something more like "ownership" for a dev on a team:
We still had company-wide mandates but again it would be an engineer on a team that either volunteered or was selected to take responsibility for some "deliverable". When the Mac was moving to PowerPC I was handed the "color pickers" from the Mac source base that were written in 68K assembly, I was expected to get them to compile for PPC. In addition to rewriting them in C, I also cleaned up the SPI that allowed the color pickers to be modular. I wasn't asked to, but I wrote a crayon color picker, an HTML color picker to test the SPI and because, at least with the HTML picker, I thought users would want that (the web being the new thing).
I had no idea then that it would not always be like this. On one hand, having to port code from 68K to C was definitely an example of the constant change I would see over the coming decades in my career. But no way did I see coming engineer-as-commodity (and I think of Agile like this, engineers are interchangeable cogs), the flip to top-down control (as in management or design telling engineers what to do instead of bottom-up where the team itself made many of the decisions).
I'll end with this: I loathe agile development. But I have seen engineers that thrive in that environment so I am not one to condemn it.
For engineers that seem unhappy I have always suggested that they be given a piece of code (or class, or part of a framework, or a whole framework if it is feasible) that they can "own".
And by own I mean they make all the changes, fix all the bugs, etc. They own the tech debt, are free (time permitting) to toss everything and rewrite it if they choose to. They chart the direction of the code going forward. They become the domain expert of that code.
For many engineers (and me of course) this can be the most rewarding way to work.
The only pushback I hear from those agile-minded is, "What if that person leaves? Now we have no domain expert regarding that code?"
They're right. Someone else will have to take it over. Perhaps even a new hire. And soon they too will "own" it — may even rewrite it. But we're engineers, we can figure this shit out. ;-)
