8 ms·

In reality there often isn't time. Getting it done > Getting it done properly as far a management is concerned.

by thepp1983 8y ago

technix32 8y ago
This is a complete fallacy IMO. The time is 10 fold down the line when people are attempting to reverse engineer in order to maintain it.
- dc_gregory 8y ago
  In this case, the evidence is that excel/word etc are doing fairly well...
- jjeaff 8y ago
  Presumably, down the road, you'll either be a defunct company or doing well enough to afford 10 times the manpower to fix things. Facebook was a spaghetti code mess in the beginning. I'm sure it caused them some growing pains, but moving too slowly early on would have likely been more costly.
  - flukus 8y ago
    > Presumably, down the road, you'll either be a defunct company or doing well enough to afford 10 times the manpower to fix things. Only in startup land which is still a small fraction of our industry. Most places will never have 10 times the manpower to fix things and are hurting themselves by not doing them properly in the first place. > Facebook was a spaghetti code mess in the beginning. I'm sure it caused them some growing pains, but moving too slowly early on would have likely been more costly. Survivor-ship bias, for every facebook how many potentially viable companies never got off the ground because users couldn't tolerate using their steaming pile?
    - SatvikBeri 8y ago
      Notably, MySpace is often cited as a company that failed because their codebase was terrible, which prevented them from adding features as quickly as Facebook could (despite having many more engineers at the time.)
      - thepp1983 8y ago
        I don't believe that for one second considering the hacks that Facebook has had to do around the limitations of PHP.
  - lazerwalker 8y ago
    Both you and this comment's parent are correct. Which doesn't say anything about the nature of software engineering or project management, but more the importance of taking context into account when considering advice.
  - Kaveren 8y ago
    I'm completely opposed to the view that bad craftsmanship is acceptable because of time constraints. You are paying for it very dearly, very soon. It is of the utmost importance to write the best code you can from the beginning, and I don't believe it slows you down very much, if at all. If you've ever seen a software product where something that should take a weekend takes months to get out, it's often not because the problem is more complicated than you'd think, but because of a mangled, complex codebase which prevents anyone from getting real work done. Edit: Removed a bunch of redundancy.
    - thepp1983 8y ago
      Well I am sorry but you are deluded. In almost any industry. You normally have 3 properties you can choose. 1. Fast 2. Cheap 3. Quality You can only pick two of those e.g. The Apollo Space program chose 1 & 3, however it was insanely expensive but the US beat the Russians.
- mixmastamyk 8y ago
  Try telling that to a pointy-haired boss.
- thepp1983 8y ago
  LOL. The long as short of it as a contractor I have to get it done. It will be probably me making the changes later and I make sure I put these things called comments in. Also developers pretending code quality is an either or proposition is a false dichotomy. You can write 80% of it in a correct manner and the other 20% could be just hacks to get it done in time. You can't write the perfect system. So I am sorry you are the one being fallacious.
Ace17 8y ago
Ever had this discussion with a coworker? Coworker: "I hadn't enough time to do it right" You: "Given enough time, how would you do it differently?" Coworker: "............" (crickets) IMHO it's not related to deadlines only ; the "not enough time" argument is often a comfortable fallacy, keeping us from facing the limits of our current skills. I found it to be especially true with testing. I've lost the count of how many times I heard "we didn't had time to write (more) tests". But testing is hard. And when given enough time, these developers don't magically start doing it "right" overnight.
- carlmr 8y ago
  >I found it to be especially true with testing. I've lost the count of how many times I heard "we didn't had time to write (more) tests". But testing is hard. And when given enough time, these developers don't magically start doing it "right" overnight. Bingo. It's not necessarily only skills though. It can be myriad reasons and "no time" is just the easiest excuse they can think of. In big companies I've often seen the company process prescribing such bad tools that a good TDD testing strategy is impossible to do with those tools, but they won't move away from them, because somebody in purchasing already bought 10,000 licenses for this bad tool (which is often just a bad GUI, which doesn't really help, except for selling the thing). The worst tool was a bad GUI where you couldn't even define functions you want to use, that had slow (>1h), non-deterministic, test execution, for a unit test.
  - thepp1983 8y ago
    To even write unit tests effectively you need to write your code in a certain differently. In C# this normally means using IOC + DI. Also almost nobody I know does proper TDD. I know it is very convincing when one of the TDD evangelists shows you how to write something like a method to work out the nth number in a fibonacci sequence using nothing but just writing tests. In reality most 95% of developers that even write tests write the logic and write the test afterwards to check the logic does what it should.
    - hprotagonist 8y ago

In reality there often isn't time. Getting it done > Getting it done properly as far a management is concerned.

This is a complete fallacy IMO. The time is 10 fold down the line when people are attempting to reverse engineer in order to maintain it.

dc_gregory 8y ago
In this case, the evidence is that excel/word etc are doing fairly well...
jjeaff 8y ago
Presumably, down the road, you'll either be a defunct company or doing well enough to afford 10 times the manpower to fix things. Facebook was a spaghetti code mess in the beginning. I'm sure it caused them some growing pains, but moving too slowly early on would have likely been more costly.
- flukus 8y ago
  > Presumably, down the road, you'll either be a defunct company or doing well enough to afford 10 times the manpower to fix things. Only in startup land which is still a small fraction of our industry. Most places will never have 10 times the manpower to fix things and are hurting themselves by not doing them properly in the first place. > Facebook was a spaghetti code mess in the beginning. I'm sure it caused them some growing pains, but moving too slowly early on would have likely been more costly. Survivor-ship bias, for every facebook how many potentially viable companies never got off the ground because users couldn't tolerate using their steaming pile?
  - SatvikBeri 8y ago
    Notably, MySpace is often cited as a company that failed because their codebase was terrible, which prevented them from adding features as quickly as Facebook could (despite having many more engineers at the time.)
    - thepp1983 8y ago
      I don't believe that for one second considering the hacks that Facebook has had to do around the limitations of PHP.
- lazerwalker 8y ago
  Both you and this comment's parent are correct. Which doesn't say anything about the nature of software engineering or project management, but more the importance of taking context into account when considering advice.
- Kaveren 8y ago
  I'm completely opposed to the view that bad craftsmanship is acceptable because of time constraints. You are paying for it very dearly, very soon. It is of the utmost importance to write the best code you can from the beginning, and I don't believe it slows you down very much, if at all. If you've ever seen a software product where something that should take a weekend takes months to get out, it's often not because the problem is more complicated than you'd think, but because of a mangled, complex codebase which prevents anyone from getting real work done. Edit: Removed a bunch of redundancy.
  - thepp1983 8y ago
    Well I am sorry but you are deluded. In almost any industry. You normally have 3 properties you can choose. 1. Fast 2. Cheap 3. Quality You can only pick two of those e.g. The Apollo Space program chose 1 & 3, however it was insanely expensive but the US beat the Russians.
mixmastamyk 8y ago
Try telling that to a pointy-haired boss.
thepp1983 8y ago
LOL. The long as short of it as a contractor I have to get it done. It will be probably me making the changes later and I make sure I put these things called comments in. Also developers pretending code quality is an either or proposition is a false dichotomy. You can write 80% of it in a correct manner and the other 20% could be just hacks to get it done in time. You can't write the perfect system. So I am sorry you are the one being fallacious.

Ace17 8y ago

Ever had this discussion with a coworker? Coworker: "I hadn't enough time to do it right" You: "Given enough time, how would you do it differently?" Coworker: "............" (crickets) IMHO it's not related to deadlines only ; the "not enough time" argument is often a comfortable fallacy, keeping us from facing the limits of our current skills. I found it to be especially true with testing. I've lost the count of how many times I heard "we didn't had time to write (more) tests". But testing is hard. And when given enough time, these developers don't magically start doing it "right" overnight.

carlmr 8y ago
>I found it to be especially true with testing. I've lost the count of how many times I heard "we didn't had time to write (more) tests". But testing is hard. And when given enough time, these developers don't magically start doing it "right" overnight. Bingo. It's not necessarily only skills though. It can be myriad reasons and "no time" is just the easiest excuse they can think of. In big companies I've often seen the company process prescribing such bad tools that a good TDD testing strategy is impossible to do with those tools, but they won't move away from them, because somebody in purchasing already bought 10,000 licenses for this bad tool (which is often just a bad GUI, which doesn't really help, except for selling the thing). The worst tool was a bad GUI where you couldn't even define functions you want to use, that had slow (>1h), non-deterministic, test execution, for a unit test.
- thepp1983 8y ago
  To even write unit tests effectively you need to write your code in a certain differently. In C# this normally means using IOC + DI. Also almost nobody I know does proper TDD. I know it is very convincing when one of the TDD evangelists shows you how to write something like a method to work out the nth number in a fibonacci sequence using nothing but just writing tests. In reality most 95% of developers that even write tests write the logic and write the test afterwards to check the logic does what it should.
  - hprotagonist 8y ago