Hacker News Reader

Comment by hakfoo | Hacker News Reader

Honestly, I prefer maintenance.

Having code that's lasted long enough to need maintenance is a sign the company has at least some grounded-in-reality fundamentals. The projects that fell apart upon learning the business model was untenable or the technical or social problem insurmountable, generally don't need maintenance programmers.

Staying a little off the bleeding edge also lets you focus on quality execution, rather than chasing the trends. Sometimes the eventual best practices aren't even offered and understood if you're adopting a platform or framework too early. Nobody wants to hit a "drop everything and rewrite because there was a huge API shift" moment.

View on HN

Nobody wants to hit a "drop everything and rewrite because there was a huge API shift" moment.

No business owner or manager wants that. I know lots of programmers for whom any excuse to throw away everything and rewrite from scratch is basically Christmas. Some of the more unscrupulous ones might even try to engineer unnecessary excuses to do just that.

Oh, I’ve seen executive leadership fall for unscrupulous/ignorant consultants pitching a “burn your stack, move everything to the cloud/LCNC/SaaS, and fire your developers” approach. Invariably either the company or the CEO’s tenure expires.

If you can offer your services recovering from these dumpster fires, you'll never go hungry as a consultant.

Ironically you may still end up being paid less than the person who started the dumpster fire

Yeah, it’s the inherent tension between wanting a client that knows they’re in a crisis, and the fact that companies in a crisis might not be able to pay you. Yes, they’re ready to make the hard decisions; no, they might not have the financial and operational latitude to actually do so.

With experience, you will learn to suss out when success is possible (for both you and the client).

I think maintenance may be growing on me, but making a judgement on whether it's a good thing is certainly multivariate.

While high turnover is almost always bad, low turnover on legacy projects might mean that critical parts of the infrastructure have been locked up by ideologues. It's not automatically bad but you should very certainly ask some pointed questions in this area. A yellow flag, if you will.

I once took a personality test. One part of it corresponded to product lifecycle: 1 was initial conception, 2 was prototype, 3 was roll-out, 4 was major enhancement, and 5 was maintenance. My personality is that I prefer prototype to roll-out. (In initial conception, there's too much uncertainty for my taste - everything is possible, but nothing is nailed down. And maintenance is boring.)

My point: You don't have to give a rational explanation of why you prefer maintenance. You can do so from your perspective, but it won't translate to those who, due to their personality, prefer other phases.

But if you want to say that projects that made it to maintenance should have money available to pay you, then yeah, you've got a point that transcends personality...

I think it depends on the developer's focus. The project I maintain was written by people who were network programming enthusiasts, so it has a number of different TCP-based transports, some of which are no longer maintained. It's made updating TLS a pain.

Reply on news.ycombinator.com