Page 5 of 5

Re: Friday Facts #366 - The only way to go fast, is to go well!

Posted: Wed Sep 01, 2021 7:33 pm
by orzelek
Sander_Bouwhuis wrote:
Wed Sep 01, 2021 7:21 pm
One of the problems I have encountered after having been a software engineer for about 25 years now is that features and fixes are billable hours, while writing tests are not billable hours. In 95% of the time I have to 'sneakily' add tests during development. Everything is a priority, everything has to be done yesterday. It's one rush job after another.
That seems like problem with your development process. Writing tests (of appropriate kind) should be part of billable hours for given task.

Re: Friday Facts #366 - The only way to go fast, is to go well!

Posted: Wed Sep 29, 2021 4:07 am
by LuxSublima
Hi Kovarex and Factorio team,

I love this Friday Facts, and wanted to share a book that you might find relevant. It is geared toward enterprise business software development, not games, but is "cut from the same cloth" as the first several paragraphs of your post:

https://www.amazon.com/Righting-Softwar ... 0136524036
("Righting Software", by Juval Löwy)

I adore programming, but the sad fact is that many of us who take that love into the "real world" and become dependent on it for a living find the corporate reality to be far less satisfying than the hobbyist ideal, if not downright soul-crushing. Mr. Löwy captures why this is quite lucidly, and with a prescription to fix it. I was pointed to it by a fellow fan of Uncle Bob's approach.

If you happen to read it, or are perchance already familiar with it, I'd love to hear your thoughts.

In any case, happy coding. :-) And I so look forward to what you release next, however long it takes. :D

Best Regards,
LuxSublima

Re: Friday Facts #366 - The only way to go fast, is to go well!

Posted: Sun Oct 10, 2021 10:27 pm
by freezerain
Hey boys, It was a pleasure to read this blog entry.

I want to share my experience with lambdas, I know they fun but keep an eye on them in path-finding or any other heavy alghorithm. While optimizing muliple heuristic I got 10%-30% improvement of function time after refactoring. Thats because compilers are usually not so good in optimizing lambdas comparing to classic approach.

Re: Friday Facts #366 - The only way to go fast, is to go well!

Posted: Thu Oct 14, 2021 7:39 pm
by ptx0
Sander_Bouwhuis wrote:
Wed Sep 01, 2021 7:21 pm
One of the problems I have encountered after having been a software engineer for about 25 years now is that features and fixes are billable hours, while writing tests are not billable hours. In 95% of the time I have to 'sneakily' add tests during development. Everything is a priority, everything has to be done yesterday. It's one rush job after another.
not at a proper company, everything we write at my company is billable and that includes tests.

Re: Friday Facts #366 - The only way to go fast, is to go well!

Posted: Sat Oct 16, 2021 8:33 am
by ssilk
ptx0 wrote:
Thu Oct 14, 2021 7:39 pm
Sander_Bouwhuis wrote:
Wed Sep 01, 2021 7:21 pm
One of the problems I have encountered after having been a software engineer for about 25 years now is that features and fixes are billable hours, while writing tests are not billable hours. In 95% of the time I have to 'sneakily' add tests during development. Everything is a priority, everything has to be done yesterday. It's one rush job after another.
not at a proper company, everything we write at my company is billable and that includes tests.
Just seeing that yet.

No matter how, but writing software includes testing. Always.
So testing is part of your business. So writing tests is of course billable, because otherwise you need to test “by hand”. So it’s just the question how to test, not if, that makes a difference.

Exception: if you write a software, that is guaranteed that it is only written once and has no deep complexity I would eventually go without writing tests (and have done several times). Typically that are converters for migrating data from old to new software, which can be straightforward programmed (just a mapping of fields for example) or other quite simple run once and throw away scripts or some hacks to see, if the idea you have really works.

This is, because the effort of writing tests pays off, if you make changes to the program or if you have to guarantee certain behavior.