4 ms·

Isn't the majority of software following this rule ? This is not specific of low/no code environment

BigJono 7y ago
Yes it is, but if you're doing the first 90% properly you have a much better shot at mitigating the difficulty of the last 10%. I think there's some vague point in any project where it goes from being 'easy' to 'hard' to add new stuff. Basically the only factor that matters for productivity is how long you can delay that point. If you just do the first 90% as quickly and cheaply as possible, you're just resigning yourself to hitting that point as early as possible.
- yebyen 7y ago
  I think this is best explained without exaggeration by the famous Design-Stamina Hypothesis[1], which states the notion that time spent on Design is something which you can trade away to improve development speed, is reliably false in the long-term (even if it seems to be working in the near term.) The graphic also suggests that there is an inflection point, as you suggest, before where time spent on design really is just slowing you down in the beginning of your project, but also that the costs of waiting too long to switch modes (from doing no design, to doing good design) after you have crossed that line, are substantial and compounding; the longer you wait, the more your lack of good design costs. And of course, not pictured, is "bad design" which can be even worse than no design. Trying to find that inflection point and put it on your development schedule in advance is also a bit like trying to catch a falling knife (not likely to succeed.) [1]: https://martinfowler.com/bliki/DesignStaminaHypothesis.html https://martinfowler.com/bliki/DesignStaminaHypothesis.html
yebyen 7y ago
Yes, absolutely. But to hear it explained that way, it just seems like wishful thinking based on a circular reasoning, that invites an invocation of the rule... "We spend too much on our developer staff, so in the future we have adopted a strategy where we will avoid most of the things that we need a team of developers for, so that our developers have less work to do, so that we can have fewer expensive devs (of which we know we cannot dispose entirely, [because we are subconsciously aware without them, there is no innovation to speak of at all.])" The problem that "Low Code" or "No Code" addresses is a real one, where devs like myself, (surely not myself, but someone more junior...) confuse poorly architected slipshod solutions for innovative ones. If we could reliably keep our code as simple as it ought to be, the market for tools like this would probably not be as large as it is.
deleted 7y ago
[deleted]
bcrosby95 7y ago
Kinda, it sounds very similar to the 80/20 rule. The 80/20 rule says 80% of the solution takes 20% of the time. So it's not quite the same. In other words, the 80/20 rule says the last 20% takes 4x as long as the first 80%. In comparison, the above quote says the last 10% takes just as long as the first 90%. So slightly different.
- rgoulter 7y ago
  Both this "90-90" and "80-20" indicate that the devil is in the detail. e.g. You can expect surprises as you're almost done, there's an inherent complexity to the solution, etc. But saying "the first 90% takes 90% of the time" blatantly ignores these anticipatable unknowns; so it's a much more tongue-in-cheek thing to say.
  - yebyen 7y ago
    The other way to read it, I guess, is that you can correctly anticipate those unknowns. The canonical way I hear is to add 1/3 to your estimates.

Yes it is, but if you're doing the first 90% properly you have a much better shot at mitigating the difficulty of the last 10%. I think there's some vague point in any project where it goes from being 'easy' to 'hard' to add new stuff. Basically the only factor that matters for productivity is how long you can delay that point. If you just do the first 90% as quickly and cheaply as possible, you're just resigning yourself to hitting that point as early as possible.

yebyen 7y ago
I think this is best explained without exaggeration by the famous Design-Stamina Hypothesis[1], which states the notion that time spent on Design is something which you can trade away to improve development speed, is reliably false in the long-term (even if it seems to be working in the near term.) The graphic also suggests that there is an inflection point, as you suggest, before where time spent on design really is just slowing you down in the beginning of your project, but also that the costs of waiting too long to switch modes (from doing no design, to doing good design) after you have crossed that line, are substantial and compounding; the longer you wait, the more your lack of good design costs. And of course, not pictured, is "bad design" which can be even worse than no design. Trying to find that inflection point and put it on your development schedule in advance is also a bit like trying to catch a falling knife (not likely to succeed.) [1]: https://martinfowler.com/bliki/DesignStaminaHypothesis.html https://martinfowler.com/bliki/DesignStaminaHypothesis.html

yebyen 7y ago

Yes, absolutely. But to hear it explained that way, it just seems like wishful thinking based on a circular reasoning, that invites an invocation of the rule... "We spend too much on our developer staff, so in the future we have adopted a strategy where we will avoid most of the things that we need a team of developers for, so that our developers have less work to do, so that we can have fewer expensive devs (of which we know we cannot dispose entirely, [because we are subconsciously aware without them, there is no innovation to speak of at all.])" The problem that "Low Code" or "No Code" addresses is a real one, where devs like myself, (surely not myself, but someone more junior...) confuse poorly architected slipshod solutions for innovative ones. If we could reliably keep our code as simple as it ought to be, the market for tools like this would probably not be as large as it is.

deleted 7y ago

[deleted]

bcrosby95 7y ago

Kinda, it sounds very similar to the 80/20 rule. The 80/20 rule says 80% of the solution takes 20% of the time. So it's not quite the same. In other words, the 80/20 rule says the last 20% takes 4x as long as the first 80%. In comparison, the above quote says the last 10% takes just as long as the first 90%. So slightly different.

rgoulter 7y ago
Both this "90-90" and "80-20" indicate that the devil is in the detail. e.g. You can expect surprises as you're almost done, there's an inherent complexity to the solution, etc. But saying "the first 90% takes 90% of the time" blatantly ignores these anticipatable unknowns; so it's a much more tongue-in-cheek thing to say.
- yebyen 7y ago
  The other way to read it, I guess, is that you can correctly anticipate those unknowns. The canonical way I hear is to add 1/3 to your estimates.