4 ms·
> revolving around the idea that the act of coding was the expensive part rather than the application complexity. I just can’t wrap my head around this idea. I
by CGamesPlay 6y ago
> revolving around the idea that the act of coding was the expensive part rather than the application complexity.
I just can’t wrap my head around this idea. If the act of coding isn’t the expensive part, then why should I have to spend so much effort coding and why can’t my effort be focused on the application complexity?
I agree that UML and past visual programming environments weren’t doing a good job of splitting these concepts, but I don’t buy that this means it’s impossible to split this.
- acdha 6y agoThere’s definitely room to shift the work but I think it’s really easy to look at the amount of time spent writing code after the specification is “done” and say that it’s overhead without questioning how much of it was really due to errors, gaps, or misunderstandings in the spec (thinking memorably of a couple of projects “overruns” where the managers who thought the plan was done were wildly out of touch with their direct reports who’d been excluded from the planning process). I think a lot of business people also liked the idea of having one expensive architect giving diagrams to cheaper coders (probably in a different county), avoiding needing to give higher pay and social status than they needed to offer to be able to hire decent programmers. Something like UML is appealing if you want something you can look at to say it’s ready to hand over to be implemented and the numbers salespeople toss around for projected cost savings can make it appealing to pretend really hard that it’s that simple.