3 ms·

Software developers are systematisers by default. We tend to value complexity for it’s own sake, hence the over-engineering common to software projects. The met

by jf- 8y ago

Software developers are systematisers by default. We tend to value complexity for it’s own sake, hence the over-engineering common to software projects. The methodologies we use fall victim to the same tendency. We build complex, rigid rule sets that are claimed to improve software or development speed or whatever else, without any actual empirical evidence that these claims are true. All you can really do is try to be knowledgeable about the methodologies, use the right tool for the right job, and try to keep things as simple as possible. And don’t subscribe to anybody’s dogma.

legulere 8y ago
The full quote by Einstein is: “Make things as simple as possible, but not simpler.” I think the second part is important to not overshoot.
- jf- 8y ago
  Well I wasn’t quoting Einstein, but sure. I would err on the side of less rather than more.
ken 8y ago
> use the right tool for the right job, and try to keep things as simple as possible Now all we need to do is get the field to agree on universally applicable definitions of "right tool" and "simple", and never change any requirement after any technical decisions have been made, and we'll be all set! I had a manager who used the term "ice cream" for phrases like this that sound good (everybody loves it!) but don't help drive any useful conversations or decisions. Should we use the right tool for the job, or the wrong one? Let's use the right one! OK, are we all agreed? Great! It's unanimous. Next issue. Unfortunately, the 5 people sitting around the table each have a completely different conception of what this means, so we're no closer to a decision than when we started. It's simply not a useful guide or metric. I think it's mostly code for "be quiet and do as I say".
- jf- 8y ago
  Depends on how needlessly argumentative your team is. Generally you can reach a consensus through discussion, example and experimentation. We do have intuition, generally we know what simple looks like when we see it, likewise we recognise what the right tool looks like as we try several. Do you want a checklist for this kind of thing? You’re not going to get one. You have to use your own judgement. Possibly you’ve fallen victim to being on teams where ego dominates, and members refuse to seek the best option unless they came up with it themselves.
draw_down 8y ago
I suppose, but to me that means we should judge methodologies or design approaches in part by evaluating their failure modes, the severity and frequency with which they occur. This is why I have so little patience for arguments like TFA, "well of course it doesn't work if you use it wrong!" You can make this argument for anything! If the thing is being used incorrectly a majority of the time, that is valuable information; it's no good to just say "well it would work if developers weren't so dumb." The happy path is always happy, by definition. A good methodology or design approach will understand its potential failure modes and include mitigations against them to help prevent those failures from happening.

by jf- 8y ago

legulere 8y ago

The full quote by Einstein is: “Make things as simple as possible, but not simpler.” I think the second part is important to not overshoot.

jf- 8y ago
Well I wasn’t quoting Einstein, but sure. I would err on the side of less rather than more.

ken 8y ago

> use the right tool for the right job, and try to keep things as simple as possible Now all we need to do is get the field to agree on universally applicable definitions of "right tool" and "simple", and never change any requirement after any technical decisions have been made, and we'll be all set! I had a manager who used the term "ice cream" for phrases like this that sound good (everybody loves it!) but don't help drive any useful conversations or decisions. Should we use the right tool for the job, or the wrong one? Let's use the right one! OK, are we all agreed? Great! It's unanimous. Next issue. Unfortunately, the 5 people sitting around the table each have a completely different conception of what this means, so we're no closer to a decision than when we started. It's simply not a useful guide or metric. I think it's mostly code for "be quiet and do as I say".

jf- 8y ago
Depends on how needlessly argumentative your team is. Generally you can reach a consensus through discussion, example and experimentation. We do have intuition, generally we know what simple looks like when we see it, likewise we recognise what the right tool looks like as we try several. Do you want a checklist for this kind of thing? You’re not going to get one. You have to use your own judgement. Possibly you’ve fallen victim to being on teams where ego dominates, and members refuse to seek the best option unless they came up with it themselves.

draw_down 8y ago

I suppose, but to me that means we should judge methodologies or design approaches in part by evaluating their failure modes, the severity and frequency with which they occur. This is why I have so little patience for arguments like TFA, "well of course it doesn't work if you use it wrong!" You can make this argument for anything! If the thing is being used incorrectly a majority of the time, that is valuable information; it's no good to just say "well it would work if developers weren't so dumb." The happy path is always happy, by definition. A good methodology or design approach will understand its potential failure modes and include mitigations against them to help prevent those failures from happening.