3 ms·

The author makes this point only somewhat implicitly, but I think for a lot of people, new feature development is the fun part of software engineering. Not for

by derf_ 2y ago

The author makes this point only somewhat implicitly, but I think for a lot of people, new feature development is the fun part of software engineering. Not for everybody (do not let me tell you how to have fun), but a substantial majority. A project's maintainers might also have lots of ideas for new features they would love to work on, but if 9 out of 10 people want to spend their time adding features, and adding the feature is only 10...25% of the work, you can see there is a problem.

hnthrow90348765 2y ago
There is also little motivation to do the hard part of maintaining things as those positions are often paid similarly but require much more work. If you can hop to jobs that only want new features while getting comp increases, where's the motivation to actually sit still and maintain something? However, I think the industry might be slowly moving against people who've never stayed at positions for a while and don't have this maintenance experience.
WJW 2y ago
It's not only that it's more fun, it's also usually the better path for self-promotion. Inside a company promotions often go towards those who have most visibly contributed to new projects. In open source projects that is of course not as prevalent, but even then many people will put open source contributions on their resume and "made big feature XYZ" is typically more impressive to recruiters than "fixed lots of small documentation and localisation problems". I don't think this is justified, as (since the article correctly describes) over time maintenance becomes much more important than the initial feature creation. But at the moment this is the world we live in and people adjust their behavior accordingly.
- derf_ 2y ago
  Management often gets rewarded for new "launches", and rarely for things that already worked continuing to work. To some degree, so does the business (although a track record of things continuing to work over a long period has value, if anyone has a time horizon beyond the next quarterly report). Meanwhile, it is more difficult to measure productivity for maintenance work, because the primary work product is understanding. Managers with the skill and experience to recognize and compensate for this are rare. Developers are not blind to these incentives.
  - marcosdumay 2y ago
    > To some degree, so does the business Sorry, but that part is wrong. The business gets rewarded for doing the same thing that was already working again and again and again. Nobody goes out of their way to buy innovative things. It's even worse, customers tend to avoid new things until they had enough time to show themselves as "not new anymore" or "more of the same". There are incredibly few exceptions, and most of them are created artificially at the cost of a large publicity budget.
Eddy_Viscosity2 2y ago
I actually get a surprising amount of statisfacation on re-writing my old code in a better way. Not even changing languages or using new fancy tools, its just that old code I still use means I know by know exactly what the real use cases are and many of the edge cases that I didn't know when I wrote it originally. So when I do the re-write, I can do it so much better because I really do know what its supposed to do without having to guess at future possible use-cases. Writing good code is less about knowing how to get it to do what its supposed to do and more about knowing what its supposed to do in the first place. In the end the new code is usually very much more compact, faster, and easier to understand. A job well done like that feels good to do.
- WJW 2y ago
  Of course. We all feel like that and that kind of thing doesn't cause any problems. Issues arise is when somebody comes in asking for new features or bugfixes in code that you haven't used for years and which you are no longer interested in. Worse is when people ask for bugfixes in software that you haven't written yourself, have never used, but are now responsible for maintaining.
  - anon22981 2y ago
    Bugfix =! rewriting code, though. Reworking an existing solution to be better is fun, but a bug fix often isn’t that. (When talking about ”rewriting code” I think of a larger scale than for example three lines of code)

by derf_ 2y ago

hnthrow90348765 2y ago

There is also little motivation to do the hard part of maintaining things as those positions are often paid similarly but require much more work. If you can hop to jobs that only want new features while getting comp increases, where's the motivation to actually sit still and maintain something? However, I think the industry might be slowly moving against people who've never stayed at positions for a while and don't have this maintenance experience.

WJW 2y ago

It's not only that it's more fun, it's also usually the better path for self-promotion. Inside a company promotions often go towards those who have most visibly contributed to new projects. In open source projects that is of course not as prevalent, but even then many people will put open source contributions on their resume and "made big feature XYZ" is typically more impressive to recruiters than "fixed lots of small documentation and localisation problems". I don't think this is justified, as (since the article correctly describes) over time maintenance becomes much more important than the initial feature creation. But at the moment this is the world we live in and people adjust their behavior accordingly.

derf_ 2y ago
Management often gets rewarded for new "launches", and rarely for things that already worked continuing to work. To some degree, so does the business (although a track record of things continuing to work over a long period has value, if anyone has a time horizon beyond the next quarterly report). Meanwhile, it is more difficult to measure productivity for maintenance work, because the primary work product is understanding. Managers with the skill and experience to recognize and compensate for this are rare. Developers are not blind to these incentives.
- marcosdumay 2y ago
  > To some degree, so does the business Sorry, but that part is wrong. The business gets rewarded for doing the same thing that was already working again and again and again. Nobody goes out of their way to buy innovative things. It's even worse, customers tend to avoid new things until they had enough time to show themselves as "not new anymore" or "more of the same". There are incredibly few exceptions, and most of them are created artificially at the cost of a large publicity budget.

Eddy_Viscosity2 2y ago

I actually get a surprising amount of statisfacation on re-writing my old code in a better way. Not even changing languages or using new fancy tools, its just that old code I still use means I know by know exactly what the real use cases are and many of the edge cases that I didn't know when I wrote it originally. So when I do the re-write, I can do it so much better because I really do know what its supposed to do without having to guess at future possible use-cases. Writing good code is less about knowing how to get it to do what its supposed to do and more about knowing what its supposed to do in the first place. In the end the new code is usually very much more compact, faster, and easier to understand. A job well done like that feels good to do.

WJW 2y ago
Of course. We all feel like that and that kind of thing doesn't cause any problems. Issues arise is when somebody comes in asking for new features or bugfixes in code that you haven't used for years and which you are no longer interested in. Worse is when people ask for bugfixes in software that you haven't written yourself, have never used, but are now responsible for maintaining.
- anon22981 2y ago
  Bugfix =! rewriting code, though. Reworking an existing solution to be better is fun, but a bug fix often isn’t that. (When talking about ”rewriting code” I think of a larger scale than for example three lines of code)