3 ms·

Point #7 are called non-functional requirements. Those are often implicit from non-technical people. Nobody will say: "I don't want to be hacked" or "i don't wa

Point #7 are called non-functional requirements. Those are often implicit from non-technical people. Nobody will say: "I don't want to be hacked" or "i don't want this system to slow down and die"... This guy says "we don't need NFRs, focus in the functional requirements"... well, that's exactly the cause behind most engineers that get fired for technical reasons: causing one or more serious incidents by not caring about those requirements. Point #2... seriously? Keep your code consistent, and if you identify opportunities for reuse for things that are related then do it. Copying and pasting code, which is what this guy is advocating for, is not good.

mathgenius 10y ago
> Copying and pasting code, which is what this guy is advocating for, is not good. Well obviously this is why we have variables and functions, etc. And hopefully this helps enforce DRY ("don't repeat yourself.") But, reusing a component leads to coupled code and that can also spell disaster. Sometimes it really is better just to copy stuff. Maybe this is a matter of taste; some people like to have the perfect design and if that makes them a happy coder then i guess you should let them do that. I find that, more often than not, the "perfect design" is not worth sweating over. My style is tracer-bullet: get it working today, write some tests maybe, and then refactor it.
- taeric 10y ago
  I like the term "tracer-bullet." You should get that written up as a blog, if it isn't already. Reminds me of an anecdote about getting people onto the moon. When that was their goal, the very first thing Nasa did was make sure they could hit the moon with a rocket. Then iterated from there.
  - TeMPOraL 10y ago
    > I like the term "tracer-bullet." The term is actually from the book Pragmatic Programmer (a good book, though I'd say mostly for beginner-to-intermediate programmers, since a lot of software blogs are essentially just repeating the contents of this book ad nauseam). I tend to do that too - get something working fast, and iterate over it. Focusing on perfect abstractions makes no sense if then you find out you're aiming in the wrong direction.
    - taeric 10y ago
      Embarrassingly, I should have known that. I just checked to make sure that wasn't where I heard the "just hit the moon" quote. I find I have been terrible at obsessing over abstractions I could be proud of. I try to instead keep my eyes on solutions I can talk to.
taeric 10y ago
I don't think it is more copy/paste that it is necessarily advocating. Rather, make sure you get real value out of anything that you abstract away. I think the specific scenario was alluded to when someone comes to read your Foo action, you want to avoid: "Found the entry point to Foo, looks like it first sets up something using Utils A. Now I need to get a rough idea of Utils A. Finally, back to Foo. Only, now it makes use of two library functions from B and C. Now, off to get a rough understanding of B and C. ..." It is possible, of course, to quickly get through all dependencies. Or, to just ignore the understanding of A, B, and C to get whatever you needed into Foo. Doing this, though, typically muddies whatever purpose A, B, and C originally had so that maintaining them will be near impossible.
NumberCruncher 10y ago
Point #7 is a sales argument for corporate software, especially for business intelligence tools. It makes easier to get the contract signed if you present such functionalities to the management. The users will hate it, because from now on they additionally have to do the business peoples work as well ("Business people never used it") but hey, who cares about them? Especially if you can sell additional trainings or consulting hours? Count yourself lucky if you don't know what I am talking about.
btbuildem 10y ago
What I often find is that the copy-and-paste turns out to be copy-paste-and-modify-slightly -- which helps describe the perimeter for the future refactor and abstraction. In this light it's helpful to duplicate a few times, to better identify what repeats and what is unique.
- deleted 10y ago
  [deleted]

mathgenius 10y ago

> Copying and pasting code, which is what this guy is advocating for, is not good. Well obviously this is why we have variables and functions, etc. And hopefully this helps enforce DRY ("don't repeat yourself.") But, reusing a component leads to coupled code and that can also spell disaster. Sometimes it really is better just to copy stuff. Maybe this is a matter of taste; some people like to have the perfect design and if that makes them a happy coder then i guess you should let them do that. I find that, more often than not, the "perfect design" is not worth sweating over. My style is tracer-bullet: get it working today, write some tests maybe, and then refactor it.

taeric 10y ago
I like the term "tracer-bullet." You should get that written up as a blog, if it isn't already. Reminds me of an anecdote about getting people onto the moon. When that was their goal, the very first thing Nasa did was make sure they could hit the moon with a rocket. Then iterated from there.
- TeMPOraL 10y ago
  > I like the term "tracer-bullet." The term is actually from the book Pragmatic Programmer (a good book, though I'd say mostly for beginner-to-intermediate programmers, since a lot of software blogs are essentially just repeating the contents of this book ad nauseam). I tend to do that too - get something working fast, and iterate over it. Focusing on perfect abstractions makes no sense if then you find out you're aiming in the wrong direction.
  - taeric 10y ago
    Embarrassingly, I should have known that. I just checked to make sure that wasn't where I heard the "just hit the moon" quote. I find I have been terrible at obsessing over abstractions I could be proud of. I try to instead keep my eyes on solutions I can talk to.

taeric 10y ago

I don't think it is more copy/paste that it is necessarily advocating. Rather, make sure you get real value out of anything that you abstract away. I think the specific scenario was alluded to when someone comes to read your Foo action, you want to avoid: "Found the entry point to Foo, looks like it first sets up something using Utils A. Now I need to get a rough idea of Utils A. Finally, back to Foo. Only, now it makes use of two library functions from B and C. Now, off to get a rough understanding of B and C. ..." It is possible, of course, to quickly get through all dependencies. Or, to just ignore the understanding of A, B, and C to get whatever you needed into Foo. Doing this, though, typically muddies whatever purpose A, B, and C originally had so that maintaining them will be near impossible.

NumberCruncher 10y ago

Point #7 is a sales argument for corporate software, especially for business intelligence tools. It makes easier to get the contract signed if you present such functionalities to the management. The users will hate it, because from now on they additionally have to do the business peoples work as well ("Business people never used it") but hey, who cares about them? Especially if you can sell additional trainings or consulting hours? Count yourself lucky if you don't know what I am talking about.

btbuildem 10y ago

What I often find is that the copy-and-paste turns out to be copy-paste-and-modify-slightly -- which helps describe the perimeter for the future refactor and abstraction. In this light it's helpful to duplicate a few times, to better identify what repeats and what is unique.

deleted 10y ago
[deleted]