3 ms·

I think the mitigating factor is "slow is smooth, smooth is fast". If you raise the quality of your codebase, you can implement those 1,000 things faster, and

I think the mitigating factor is "slow is smooth, smooth is fast". If you raise the quality of your codebase, you can implement those 1,000 things faster, and you reduce the odds of they'll have to be reworked.

animal_spirits 2y ago
This only works if you are in charge of the timelines or have a manager who values quality over quantity
- ajmurmann 2y ago
  And/or an organization that has the faith and politics that allow to wait till smooth starts paying back and becomes fast. Frequently you also have everyone benefiting from smoothness but not everyone contributing to it which results in the folks who pump out tickets as fast as possible looking like they are just strictly better. Easy to adapt to and game as an IC, but I find it frustrating as a manager.
  - netdevnet 2y ago
    > wait till smooth starts paying back and becomes fast By that time, you will have probably left the company and someone with less care about code quality will come and undo your work. Also, like security, it is hard to show to a manager data and graphs showing how much we are saving
    - ajmurmann 2y ago
      Yes, very true. You can only make it work if everyone is bought in and even then it's ready to regress by someone skipping steps and getting praise from the business while other engineers are fixing their stuff.
- KronisLV 2y ago
  > This only works if you are in charge of the timelines or have a manager who values quality over quantity And also if you're not in a bad starting position: you could have a system that is very hard and slow to work with, meaning that you can't feasibly introduce much easy to use functionality, especially if the domain logic is tightly coupled.
pif 2y ago
> smooth is fast Such reasoning is based on a flawed assumption: that the value of time is constant in time. While smooth is indeed fast in the long run, it is slower in the short run, and time before the release date is much, much, much more worthy than time after the deadline. Shipping functionalities now and bugfixes later is what pays your salary. Waiting for the perfect code makes your customer seek comfort at your competition.
- tokinonagare 2y ago
  Most deadline are fake.
  - netdevnet 2y ago
    Tell that to the customer, as a web/mobile agency, when they ask you to contractually commit to a date for the release of their web app
    - yamazakiwi 2y ago
      Or when your boss sets a goal for 0 missed deadlines and lets people go for not hitting them.
  - pif 2y ago
    Yes and no. External deadlines are often meaningless, but customers are not the only users of the application. Once you release your part and keep developing/debugging/polishing your code, your colleagues can move on with their job and so on and so on. As unfortunate and unnatural as this may seem to us programmers, shipping _is_ a feature in professional software development; and, in the quality/time continuum, "something now" beats "all of it tomorrow" in every scenario. PS: I do get that the decision on releasing a product to the public has different constraints in the medical or aeronautical industry than a photo sharing website, still enabling the rest of the organization to move on with their tasks is too often underrated.
  - fmbb 2y ago
    Yes indeed. But you still have to put your stuff out there to test it. All code is a cost. Features are what users pay for. There is scarcely objectively good code. One person’s smooth is another person’s rough. Deliver stuff. Act on user feedback. If you are not developing commercial software, the above is invalid advice.
netdevnet 2y ago
In the world of professional software development, economic value is king. This rule has marginal declining utility after some point and in some cases it is just not worth it. Think prototyping, tight deadlines, etc. In an ideal world, taking some additional time pays off, in other worlds, it doesn't and gets you in PIP. inb4 you say that's not the kind of company you want to work in, most companies are like these and not everyone can afford to apply and get a place at the 2 companies in your country where code quality is actually valued
- zusammen 2y ago
  [dead]

animal_spirits 2y ago

This only works if you are in charge of the timelines or have a manager who values quality over quantity

ajmurmann 2y ago
And/or an organization that has the faith and politics that allow to wait till smooth starts paying back and becomes fast. Frequently you also have everyone benefiting from smoothness but not everyone contributing to it which results in the folks who pump out tickets as fast as possible looking like they are just strictly better. Easy to adapt to and game as an IC, but I find it frustrating as a manager.
- netdevnet 2y ago
  > wait till smooth starts paying back and becomes fast By that time, you will have probably left the company and someone with less care about code quality will come and undo your work. Also, like security, it is hard to show to a manager data and graphs showing how much we are saving
  - ajmurmann 2y ago
    Yes, very true. You can only make it work if everyone is bought in and even then it's ready to regress by someone skipping steps and getting praise from the business while other engineers are fixing their stuff.
KronisLV 2y ago
> This only works if you are in charge of the timelines or have a manager who values quality over quantity And also if you're not in a bad starting position: you could have a system that is very hard and slow to work with, meaning that you can't feasibly introduce much easy to use functionality, especially if the domain logic is tightly coupled.

pif 2y ago

> smooth is fast Such reasoning is based on a flawed assumption: that the value of time is constant in time. While smooth is indeed fast in the long run, it is slower in the short run, and time before the release date is much, much, much more worthy than time after the deadline. Shipping functionalities now and bugfixes later is what pays your salary. Waiting for the perfect code makes your customer seek comfort at your competition.

tokinonagare 2y ago
Most deadline are fake.
- netdevnet 2y ago
  Tell that to the customer, as a web/mobile agency, when they ask you to contractually commit to a date for the release of their web app
  - yamazakiwi 2y ago
    Or when your boss sets a goal for 0 missed deadlines and lets people go for not hitting them.
- pif 2y ago
  Yes and no. External deadlines are often meaningless, but customers are not the only users of the application. Once you release your part and keep developing/debugging/polishing your code, your colleagues can move on with their job and so on and so on. As unfortunate and unnatural as this may seem to us programmers, shipping _is_ a feature in professional software development; and, in the quality/time continuum, "something now" beats "all of it tomorrow" in every scenario. PS: I do get that the decision on releasing a product to the public has different constraints in the medical or aeronautical industry than a photo sharing website, still enabling the rest of the organization to move on with their tasks is too often underrated.
- fmbb 2y ago
  Yes indeed. But you still have to put your stuff out there to test it. All code is a cost. Features are what users pay for. There is scarcely objectively good code. One person’s smooth is another person’s rough. Deliver stuff. Act on user feedback. If you are not developing commercial software, the above is invalid advice.

netdevnet 2y ago

In the world of professional software development, economic value is king. This rule has marginal declining utility after some point and in some cases it is just not worth it. Think prototyping, tight deadlines, etc. In an ideal world, taking some additional time pays off, in other worlds, it doesn't and gets you in PIP. inb4 you say that's not the kind of company you want to work in, most companies are like these and not everyone can afford to apply and get a place at the 2 companies in your country where code quality is actually valued

zusammen 2y ago
[dead]