Comment by lz400
3 months ago
Like many others in the comments, I feel there are a lot of assumptions in this piece. Before, coding is only 14% therefore, small slice. I think that's a very superficial assumption. That was because coding was expensive and we needed to be sure we didn't code the wrong thing. If code is as cheap as it is now, we will optimize differently, we will structure around it. Instead of so many meetings we will code 5 different versions of the same thing and choose, etc.
> That was because coding was expensive and we needed to be sure we didn't code the wrong thing.
Coding has never been expensive as it is nothing more than a reification of a solution to a problem as it is understood at that time.
It is the underlying understanding of the problem which has always been expensive and remains so.
Coding was expensive in the sense that once you decided what to do, it took a few engineers months / years to do moderately complex projects. That's not true anymore. Therefore the risk of "coding the wrong thing" is less.
Is it? The temptation to start without a thorough design is now much stronger because the implementation osnperceived to be cheap and easy to replace. But if you start building the wrong thing fast, you still get the right thing later than when you had checked properly at the start.
1 reply →
Lots os engineering projects took as long as you mentioned because they were horribly specified. Then the engineer either waits for an answer (which they generally do not get) or takes a decision (which might not be ideal without domain knowledge). Then you release and the customer suddenly starts explaining what they want.
You can improve some parts with LLM (make more prototypes, iterate faster), but if humans are the bottleneck and the problem itself is complex it will not be 10x improvement.
Of course, maybe we talk about different type of project, there are also the type of projects like "a web-shop that sells stuff" that someone considered "expensive to code".
2 replies →
> Coding was expensive in the sense that once you decided what to do, it took a few engineers months / years to do moderately complex projects. That's not true anymore.
This conflates two orthogonal concerns; understanding what needs to be done with encoding a solution for what needs to be done. I am reminded of an axiom I have long held:
> Therefore the risk of "coding the wrong thing" is less.
I disagree with the proposition that being able to generate "wrong code faster" has anything to do with understanding what ultimately needs to be done. In fact, exploratory efforts having the intent to refine problem domain understanding (a.k.a. "proof of concept" projects) is an established industry technique whose work product is best discarded.
> Before, coding is only 14% therefore, small slice.
But also, no, because they write:
> “coding” (not including bug fixing, testing, etc.)
What if bug fixing includes "coding", or "writing code", or however one would want to define that? Especially in the enterprise setting they evoke, a lot of work will not be "coding" in the sense of churning out new features, but "coding" in the sense of fixing bugs. I know a lot of my "coding" is in this category. But we're not given a number for it. I suspect the slice would be bigger if they included this type of "coding".
So you're suggesting that coding will take more of the PRD phase?
Basically yes, there will be more coding in that phase, more prototyping, the PRD phases will be shorter too, there will be more pressure to deliver quickly and the PRDs will be under more pressure to move more quickly. This is what I'm already seeing to be honest.