factories aim to minimize variance, which in an informational sense mean minimize entropy. LLMs take a seed of entropy and run with it, decompress it if you will. if the goal of a software factory is to turn wishes encoded in english into software systems the work well. the only way to do this in a factory sense is if all the parts have been built, and it’s just a matter of putting them together. maybe they are maybe they aren’t. moreover the work of software development is a process of refining and discovering value. it is in some sense empirical that comes down to taste. does Apple make the best software? maybe. but they have a high degree of taste in the sense of having an opinionated and cohesive ecosystem which people pay a premium for. the slop that churns from the llm chat interface is hacked together tech debt at current - not cohesive product design - unless there’s a person there constraining it.
Isn't that what manufacturers are doing as well? They also have their R&D departments for the new to explore, not fully specified product ideas that may or may not become standardized. They leverage their production capabilities where it makes sense for it and move to manual/human labor where it doesn't.
Perhaps software factory is a too strict term right now. But I never read it like you are either a software factory or you're in software manufacturing. In my head both flavors exist in parallel. In fact, I think that without people on board that know how to build software, you won't be able to build and maintain a proper factory.
true, it just always felt that R&D part of software is way more than the manufacturing part and the more the manufacturing gets faster, the more R&D is becoming important.
The answer is always somewhere in the middle as usual.
For me, development has been like this, for example I need to build a service with MongoDB. Do I know MongoDB? No - > then I need to take it slow, learn the tech, learn it's quirks, write a couple of dummy stuff, before I move to using it in my product.
Next time I need to use MongoDB - > I'll jist take parts of my previous code, or just choose whatever the best oss framework is and trust it. Or even if it's not MongoDB but some other NoSQL with its quirks.
And this process is different from person to person, and this is part of being a senior. You've gone through the motion, collected knowledge.
Now, I'm saying, put into factory whatever you've gone through once already. And I guess that's how a SF can become powerful, if everyone on the team puts there something they really know.
Once we start putting discovery work there, I think we'll get all the problems of knowledge loss, bugs that we don't understand and can't handle fast, etcetc.
Software ‘manufacturing’, in it’s logical sense, is pressing CDs or spinning up load balancers. Why people mean by a software factory is design and development with predictable cost constraints.
Right on
factories aim to minimize variance, which in an informational sense mean minimize entropy. LLMs take a seed of entropy and run with it, decompress it if you will. if the goal of a software factory is to turn wishes encoded in english into software systems the work well. the only way to do this in a factory sense is if all the parts have been built, and it’s just a matter of putting them together. maybe they are maybe they aren’t. moreover the work of software development is a process of refining and discovering value. it is in some sense empirical that comes down to taste. does Apple make the best software? maybe. but they have a high degree of taste in the sense of having an opinionated and cohesive ecosystem which people pay a premium for. the slop that churns from the llm chat interface is hacked together tech debt at current - not cohesive product design - unless there’s a person there constraining it.
Taylorism is always the worst idea.
Isn't that what manufacturers are doing as well? They also have their R&D departments for the new to explore, not fully specified product ideas that may or may not become standardized. They leverage their production capabilities where it makes sense for it and move to manual/human labor where it doesn't.
Perhaps software factory is a too strict term right now. But I never read it like you are either a software factory or you're in software manufacturing. In my head both flavors exist in parallel. In fact, I think that without people on board that know how to build software, you won't be able to build and maintain a proper factory.
true, it just always felt that R&D part of software is way more than the manufacturing part and the more the manufacturing gets faster, the more R&D is becoming important.
The answer is always somewhere in the middle as usual.
For me, development has been like this, for example I need to build a service with MongoDB. Do I know MongoDB? No - > then I need to take it slow, learn the tech, learn it's quirks, write a couple of dummy stuff, before I move to using it in my product.
Next time I need to use MongoDB - > I'll jist take parts of my previous code, or just choose whatever the best oss framework is and trust it. Or even if it's not MongoDB but some other NoSQL with its quirks.
And this process is different from person to person, and this is part of being a senior. You've gone through the motion, collected knowledge.
Now, I'm saying, put into factory whatever you've gone through once already. And I guess that's how a SF can become powerful, if everyone on the team puts there something they really know.
Once we start putting discovery work there, I think we'll get all the problems of knowledge loss, bugs that we don't understand and can't handle fast, etcetc.
Sorry for long answer 😬
You run into a huge number of problems only once you’re actually building 'a' thing. :D
Software ‘manufacturing’, in it’s logical sense, is pressing CDs or spinning up load balancers. Why people mean by a software factory is design and development with predictable cost constraints.