I hate this phrase. In the last two years the word “resource” has completely replaced words like “developer” or “person” at my company .
I guess since it has been widely claimed that a corporation’s purpose is to make money for the owners and nothing else it makes sense to rid the workplace of any semblance of humanity. No privacy, no loyalty from the side of the company and now slowly people aren’t being addressed as people anymore.
We use that term a lot at my job. It's specifically used a generic term to track utilization rates and project headcount needs so we can guess how many people we need to hire. We've been calling this practice Human Resources for decades. It doesn't mean we don't know who our people are or that they are all individuals with unique personalities and talents.
And it seems to me that employee loyalty is degrading far faster than employer loyalty, so it goes both ways.
Enterprise web development (or any enterprise development) has always been dehumanizing. It´s the vertical organizational model applied to software development. The enterprise implementation of Agile is just the vertical model in new clothes (status meetings disguised as daily meetings, story points used for stack-ranking, etc). When you enter the enterprise you trade leverage for job stability and 9-to-5 working hours.
Startups and mid or small sized niche companies are a little more human. But here you tend to get long working hours and more stress, plus sometimes they are also "vertical".
While the author implicates Agile, it seems like their real problem is with software development at scale, or really, any production process at scale. Once you've come up with a design (the fun part), you are faced with the prospect of implementation (the not-so-fun part). If that implementation includes so much work that you need a bunch of people to do it, you are left with the inevitable task of decomposing and distributing the work (into widgets or services or subroutines, or however you functionally break down the system). Whether you do Agile or not, that work is going to have to involve requirements and acceptance criteria, and tracking and reporting and scheduling.
But all of that doesn't have to be dehumanizing. Nothing in Agile says you have to call people "resources." Or that you can't say things like “Oh, Samantha would be a great fit for this project.” And if your Agile team's primary motivation is to move tickets from one column to another, you should fire your Agile management team, because that is literally antithetical to the Agile process, which focuses on delivered value.
Yeah it's not Agile's fault but it's a tool that makes it easy for bad mangers to squeeze every last bit of productivity out of people in dehumanizing ways through the power of the velocity curve.
At least in the past bad managers had no access to such tools so their power to harm was limited a bit.
" Agile, it seems like their real problem is with software development at scale, or really, any production process at scale."
I think it's more unique to software development. You don't see this kind of approach in large scale construction project with layers of contractors and subcontractors covering dozens of disciplines. You don't see this in car industry where they can do design, engineering, testing, factory tooling in 3 years.
I really believe the only reason why we do it in software is because we can.
And we can get away with it.
I also think the proliferation of outsourcing and offshoring was a strong catalyst for various reasons, though I'm sure that's a sensitive topic.
When industries that cannot get away with doing so tries, plane falls out of sky.
I think Agile can be great, but having been in the industry for 20 years and being put to practice, I see more reluctant Agile than true Agile. Meaning, people don't like it, but it has perception of working, so they go along with it, because there doesn't appear to be impetus to move away from it.
First, construction and automotve have been around for over a century, and they definitely suffered through growing pains in their discipline - there are boondoggles galore in the engineering and infrastructure space, and for the same reasons as bad software - a lack of clear vision and product fit.
And of course secondly they are subject to a much more rigid set of constraints to define success - primarily the hard laws of physics, chemistry, and human physiology.
But the key difference hands down is the raison d'etre - the demand for cars, buildings, bridges, roads, airplanes is self-evident.
Almost no software rises to such an elemental need in our world. The ones that do (Linux, avionics firmware, etc) don't run on Agile.
You don't see this kind of approach in large scale construction project with layers of contractors and subcontractors covering dozens of disciplines. You don't see this in car industry where they can do design, engineering, testing, factory tooling in 3 years.
I think you do see it in construction and automotive assembly: the project is decomposed into small pieces and tackled by large numbers of specialists, who are individually regarded as interchangeable. Or when you say "this kind of approach" are you thinking of something else?
So I played a lot Overwatch for the two years after it came out. (I swear, this is relevant.)
For the uninitiated, Overwatch at release gave players more freedom than any shooter on the market. Pretty much any effect you wanted (mass teleportation? Energy shields? Hacking? Automated turrets? Sonar? Lifedrain?) was available to you if you switched to the appropriate hero.
And the players started eating each other alive.
See, diversity of abilities means that some will synergize well together. But those parts are not necessarily equal; it's usually more fun to mow down opponents than to carry ammo around, for instance. So gamers, being dicks, will insist that other people do the boring stuff like carry ammo or whatever, then retreat to the motte of "Don't you want to play as a team?" when called on this.
I got really idealistic about this game, and wanted to play it in a way that respected and supported the humans on my team.
What I found was that the best way to do that was to pick heroes with which I could reduce existential risk, (channeling Taleb) thereby not constricting my teammates into "Do X or we lose the game immediately" situations. This increased the options available to my teammates.
In an ideal world, they'd have reciprocated and made my flexibility a priority as well, but, well, it's online gaming.
So the status quo was players yelling at each other to do X_UNFUN_THING that (supposedly) synergized with Y_FUN_THING.
Well, after three years the developers got sick of the players arguing with each other and enforced some structure.
This is how I feel about Agile, and software in the large. There are a zillion degrees of freedom available to individuals, who use that freedom in ways that have negative externalities for other stakeholders. Those stakeholders are doing the same, of course, and now you have a coordination problem.
What does it mean to write software in such a way that you create/preserve options for other parties? How do they act to do the same for you?
It systematically simulates integrated circuit systems and large industrial production lines.
In the computer field, for the first time, it was realized that the unification of hardware engineering and software engineering on the logical model. It has been extended from `Lisp language-level code and data unification` to `system engineering-level software and hardware unification`.
It brings large industrial production theory and methods to software engineering. It incorporates IT industry into modern standardized large industrial production systems, This is an epoch-making innovative theory and method.
1. The replaceability, insertability, observability, and readability of the pipeline are very strong.
2. The observability, standard, fairness of the dataflow are very strong. Data standards (data interfaces, data specifications) are better than code interfaces. and non-IT practitioners can understand.
3. The warehouse/workshop model is widely adaptable, simple, and reliable, and the workshops are isolated from each other.
18 comments
[ 0.19 ms ] story [ 50.5 ms ] threadI hate this phrase. In the last two years the word “resource” has completely replaced words like “developer” or “person” at my company .
I guess since it has been widely claimed that a corporation’s purpose is to make money for the owners and nothing else it makes sense to rid the workplace of any semblance of humanity. No privacy, no loyalty from the side of the company and now slowly people aren’t being addressed as people anymore.
And it seems to me that employee loyalty is degrading far faster than employer loyalty, so it goes both ways.
Employer loyalty has gone down to pretty much zero so employees still have a lot of catching up to do.
Startups and mid or small sized niche companies are a little more human. But here you tend to get long working hours and more stress, plus sometimes they are also "vertical".
But all of that doesn't have to be dehumanizing. Nothing in Agile says you have to call people "resources." Or that you can't say things like “Oh, Samantha would be a great fit for this project.” And if your Agile team's primary motivation is to move tickets from one column to another, you should fire your Agile management team, because that is literally antithetical to the Agile process, which focuses on delivered value.
At least in the past bad managers had no access to such tools so their power to harm was limited a bit.
I think it's more unique to software development. You don't see this kind of approach in large scale construction project with layers of contractors and subcontractors covering dozens of disciplines. You don't see this in car industry where they can do design, engineering, testing, factory tooling in 3 years.
I really believe the only reason why we do it in software is because we can.
And we can get away with it.
I also think the proliferation of outsourcing and offshoring was a strong catalyst for various reasons, though I'm sure that's a sensitive topic.
When industries that cannot get away with doing so tries, plane falls out of sky.
I think Agile can be great, but having been in the industry for 20 years and being put to practice, I see more reluctant Agile than true Agile. Meaning, people don't like it, but it has perception of working, so they go along with it, because there doesn't appear to be impetus to move away from it.
And of course secondly they are subject to a much more rigid set of constraints to define success - primarily the hard laws of physics, chemistry, and human physiology.
But the key difference hands down is the raison d'etre - the demand for cars, buildings, bridges, roads, airplanes is self-evident.
Almost no software rises to such an elemental need in our world. The ones that do (Linux, avionics firmware, etc) don't run on Agile.
The rest: who really (really) cares?
I think you do see it in construction and automotive assembly: the project is decomposed into small pieces and tackled by large numbers of specialists, who are individually regarded as interchangeable. Or when you say "this kind of approach" are you thinking of something else?
For the uninitiated, Overwatch at release gave players more freedom than any shooter on the market. Pretty much any effect you wanted (mass teleportation? Energy shields? Hacking? Automated turrets? Sonar? Lifedrain?) was available to you if you switched to the appropriate hero.
And the players started eating each other alive.
See, diversity of abilities means that some will synergize well together. But those parts are not necessarily equal; it's usually more fun to mow down opponents than to carry ammo around, for instance. So gamers, being dicks, will insist that other people do the boring stuff like carry ammo or whatever, then retreat to the motte of "Don't you want to play as a team?" when called on this.
I got really idealistic about this game, and wanted to play it in a way that respected and supported the humans on my team.
What I found was that the best way to do that was to pick heroes with which I could reduce existential risk, (channeling Taleb) thereby not constricting my teammates into "Do X or we lose the game immediately" situations. This increased the options available to my teammates.
In an ideal world, they'd have reciprocated and made my flexibility a priority as well, but, well, it's online gaming.
So the status quo was players yelling at each other to do X_UNFUN_THING that (supposedly) synergized with Y_FUN_THING.
Well, after three years the developers got sick of the players arguing with each other and enforced some structure.
This is how I feel about Agile, and software in the large. There are a zillion degrees of freedom available to individuals, who use that freedom in ways that have negative externalities for other stakeholders. Those stakeholders are doing the same, of course, and now you have a coordination problem.
What does it mean to write software in such a way that you create/preserve options for other parties? How do they act to do the same for you?
I think that's the place to start.
It systematically simulates integrated circuit systems and large industrial production lines.
In the computer field, for the first time, it was realized that the unification of hardware engineering and software engineering on the logical model. It has been extended from `Lisp language-level code and data unification` to `system engineering-level software and hardware unification`.
It brings large industrial production theory and methods to software engineering. It incorporates IT industry into modern standardized large industrial production systems, This is an epoch-making innovative theory and method.
1. The replaceability, insertability, observability, and readability of the pipeline are very strong.
2. The observability, standard, fairness of the dataflow are very strong. Data standards (data interfaces, data specifications) are better than code interfaces. and non-IT practitioners can understand.
3. The warehouse/workshop model is widely adaptable, simple, and reliable, and the workshops are isolated from each other.
There are only five basic components:
1. Pipeline (pure function)
2. Branch
3. Reflow (feedback, whirlpool, recursion)
4. Shunt (concurrent, parallel)
5. Confluence.