
Design systems, agile, and industrialization - myth_drannon
https://bradfrost.com/blog/post/design-systems-agile-and-industrialization/
======
vannevar
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.

~~~
pcurve
" 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.

~~~
kthejoker2
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.

The rest: who really ( _really_ ) cares?

------
gfs78
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".

------
invalidOrTaken
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?

I think that's the place to start.

------
lincpa
[The Pure Function Pipeline Data Flow v3.0 with Warehouse/Workshop
Model]([https://github.com/linpengcheng/PurefunctionPipelineDataflow](https://github.com/linpengcheng/PurefunctionPipelineDataflow))

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.

------
Ididntdothis
“a developer resource is needed”

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.

~~~
tootie
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.

~~~
jimbob45
I always thought HR was meant to mean resources _for_ humans, not humans as
resources.

