Just because something is subtractive doesn't mean the boundaries are clear. The point is, at some point in the future, the project will be done.
Even if we don't know the boundaries of that, you can still locally look and decide "I have developed expertise here, which means I am the best or even only person to do this other part."
There is an interesting discussion about recognizing the boundaries of the project, but that is also very much an issue someone with an additive mindset has.
If you believe you are creating value, you will happily start doing work that falls outside the boundaries of what is needed, whilst leaving behind other things that really need to be done.
So making a car is subtractive work? At some point in the future the work is done and the car shipped. Doesn't seem like a useful construct, everything is subtractive then.
Just like a software project if someone does shoddy parts of the car it will greatly detract from the value of the car even if the other 99% are in stellar condition. That is true for almost everything, the weakest link mostly determines the quality of your product so to ship good products you need to ensure nobody does shoddy work. The work is still additive though, just that producing shoddy pieces is negative value if quality is so low that it makes the product unsellable.
I would argue that, yes, making a single car is subtractive work. There is a specific and finite list of tasks that have to be done to make one car. It doesn’t help to make ten steering wheels for one car. If you’re working in a mass assembly plant, sure, go ahead, they’ll all get used. But otherwise, each piece of work needs to support a single clearly defined goal - a working car. More is not always better.
I think there is a difference in the concepts the author describes that comes from the fact that in the car manufacturing process, the goal is to produce a large number of cars. So someone can continue to linearly add value by producing more of the same thing. Your value is based on the sum of your total output.
To contrast with software: you reach a point where continuing to crank out more of the same doesn't actually create value. Your value is based on how much of the overall body of work you addressed. How big of a piece did you take out from the whole pie.
Personally, I'm still thinking over the additive/subtractive concept. It does seem like you could reframe a problem either way. Include a daily quota and the car example becomes subtractive.
> Your value is based on the sum of your total output.
If you make 2x car parts per unit of time than you usually do, you'll probably net the plant 1x the profit, because everyone else is working at 1x rate and your extra parts won't be used faster anyway. If you make 4x car parts per unit of time, you might net the company a $1M of loss, because the supply chain people won't be expecting the components to run out so fast and you'll stall the whole assembly line until the logistics can be sorted out.
It seems to me that "addictive"/"subtractive" split doesn't work for any job if you analyze it with the thoroughness the article otherwise applies to software development.
Did you miss the part where the author contrasts the subtractive work mentality in a creative process from the additive work mentality on an assembly line? Your thoughts are addressed by the piece.
Designing a car: iterative, convergent process that can be modeled as subtractive
Building a car in a factory assembly line from a static design: additive work
But the word subtractive doesn't make sense though unless you know exactly what the end product will be. And if you know exactly what the end product will be then designing the car is not fundamentally different from building it since in essence the car is already designed, you just hammer out the details. A programmer who just picks tasks from a kanban is not creative, he just adds code to do the thing the board requests. Doing more stuff from the board all else being the same is always better, he is an additive worker. If he does it faster but produce shoddy work it is the same as if a factory worker works faster but produce shoddy parts on the car, meaning he will get fired because he ruins it.
In most orgs of a size, only a handful of people are adding tickets to the queue. And even then, that's only an "additive workflow" if you insist on ignoring the system the author is describing.
Whether you know all the work to be done or not, there is a quantity of work to be done after which there will be no more work to do. Some of that work might be learning what all the work is. Some of the work might be defining how to do some of the other work. Other work is just picking work off of the pile and doing it. All of these are subtracting from the total quantity of work that will have been done by completing the project.
Not knowing the quantity or boundaries does not change this nature.
> Whether you know all the work to be done or not, there is a quantity of work to be done after which there will be no more work to do.
Does that imply the existential possibility of a finished software product? To me it is precluded by ever-changing requirements and impossibility of bug-free software.
> Some of that work might be learning what all the work is. Some of the work might be defining how to do some of the other work. … All of these are subtracting from the total quantity of work that will have been done by completing the project.
If an activity changes the pile of work, can it be positively claimed subtraction took place?
Given pile of work A and activity ƒ, we can say ƒ is subtractive only if its intention was to make ƒ(A) ⊆ A.
If ∂(A) ⊊ A (intentionally, not because some regressions were accidentally introduced), then I don’t see how ∂ is subtractive. New pile of work may be (but doesn’t have to be) smaller, but it is not a subset of the original pile.
I believe a lot of activity is like ∂, especially in smaller teams where enabling continuous pile-of-work redefinition may be more beneficial than subtracting from the pile.
Interesting. I wonder if we are talking about different things.
To me unclear boundaries imply a degree of exploration and boundary-setting activity, and that is rarely plain subtractive.
True, in a bigger picture this boundary-setting activity still works towards completing some solution—but then in an even bigger picture, I would put forward that in the real world projects are never actually complete.
As a maybe far-fetched example, say there is such and such real-world user problem that was usually addressed via use of spreadsheet- or CRUD website based solutions; now a teammate delivers an Electron-based app prototype which shifts the constraints of what we can do or what level of effort it takes, and even prompts a reformulation of user’s true needs as possibilities previously not even thought about are suddenly on the radar.
Even if we don't know the boundaries of that, you can still locally look and decide "I have developed expertise here, which means I am the best or even only person to do this other part."
There is an interesting discussion about recognizing the boundaries of the project, but that is also very much an issue someone with an additive mindset has.
If you believe you are creating value, you will happily start doing work that falls outside the boundaries of what is needed, whilst leaving behind other things that really need to be done.