Because when it is to actually get paid work done, all the bloat adds up and that 3 days upfront could shave weeks/months of your yearly tasks. XKCD has a topic abut how much time you can spend on a problem before effort outweighs productivity gains.
If the tasks are daily or hourly you can actually spend a lot of time automating for payback
And note this is one instance of task, imagine a team of people all using your code to do the task, and you get a quicker ROI or you can multiply dev time by people
Agreed. Or look at the manual effort, is it worth coding it, or just do it manually for one offs. A coworker would code a bunch of mundane tasks for single problems, where I would check if it actually will save time or I just manually manipulate the data myself.
SDLC can be made to be inefficient to maximize billable hours, but that doesn’t mean the software is inherently badly architected. It could just have a lot of unnecessary boilerplate that you could optimize out, but it’s soooooo hard to get tech debt prioritized on the road map.
Killing you own velocity can be done intelligently, it’s just that most teams aren’t killing their own velocity because they’re competent, they’re doing it because they’re incompetent.
And note this is one instance of task, imagine a team of people all using your code to do the task, and you get a quicker ROI or you can multiply dev time by people
In practice, is only quicker ROI if your maintenance plan is nonexistent.
Because when it is to actually get paid work done, all the bloat adds up and that 3 days upfront could shave weeks/months of your yearly tasks. XKCD has a topic abut how much time you can spend on a problem before effort outweighs productivity gains. If the tasks are daily or hourly you can actually spend a lot of time automating for payback
And note this is one instance of task, imagine a team of people all using your code to do the task, and you get a quicker ROI or you can multiply dev time by people
That also goes to show why to not waste 3 days to shave 2 seconds off a program that gets run once a week.
Agreed. Or look at the manual effort, is it worth coding it, or just do it manually for one offs. A coworker would code a bunch of mundane tasks for single problems, where I would check if it actually will save time or I just manually manipulate the data myself.
You can write perfectly well structured and maintainable code in Python and still be more productive than in other languages.
This site has good benchmarking of unoptimized and optimized code for several languages. C+ blows Python away. https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html
SDLC can be made to be inefficient to maximize billable hours, but that doesn’t mean the software is inherently badly architected. It could just have a lot of unnecessary boilerplate that you could optimize out, but it’s soooooo hard to get tech debt prioritized on the road map.
Killing you own velocity can be done intelligently, it’s just that most teams aren’t killing their own velocity because they’re competent, they’re doing it because they’re incompetent.
In practice, is only quicker ROI if your maintenance plan is nonexistent.