6 ms·
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 an
by lz400 1mo ago
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.
- gmueckl 1mo agoIs 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.
- bob001 1mo agoCICD and iterative development and agile work because interactive building leads to better product. Otherwise we'd all build perfect software using waterfall methodologies and release only once a year. If implementation is cheap then you implement, review and then re-implement. Not even iterate in the extreme case. Throw it away if needed and start from scratch if needed.
- vladms 1mo agoLots 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".
- bob001 1mo agoSpecification is hard because you are trying to predict a future state in a vacuum. You need to do that because creating the product is very expensive coding wise. If instead you could instantly build to your current specification then you could iterate on the specification against a real product. Even if all that code is thrown out the end result would be a better specification.
- vladms 1mo agoFor some projects specification is also hard because of interdependence between modules or data or parts of the project. To which you might answer "make more tests". And we turn in circles, because it is hard to test something you did not thought of. My experience is that users (customers) even when presented with a prototype (done fast by AI, or previously, in the slow way) can take days to "discover" or "think" about things they wish. Then more days to understand why some wishes can't be done because it breaks other stuff they want. Maybe you have smarter, faster, more experienced and decided users. Then I can only say: good for you, you are lucky!
- AdieuToLogic 1mo ago> 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: When making software, remember that it is a snapshot of your understanding of the problem. It states to all, including your future-self, your approach, clarity, and appropriateness of the solution for the problem at hand. Choose your statements wisely. > 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.