Hacker News Reader

It all depends on the structure of the organisation, and how well managed it is.

Imagine an organisation where developers are adding features to the service, where each new feature uses $1000 of disk space and enables $10,000 of new sales.

And imagine the sysadmins buy huge file servers, each new file server costs $500,000

In a highly bureaucratic organisation, the sysadmins will cross-charge the developers for disk space, and they'll already have the money ready when a new file server is needed.

In a well run and less bureaucratic organisation, the bosses will realise that $500,000 bill enables projects that will return $5M, so they'll gladly pay it.

In a poorly run organisation, the bosses will blanch at the $500,000 bill because it's expensive and not linked to a project; the sysadmins will ask the next person who needs $1000 of disk space to pay $500,000 for it (they'll refuse); then the sysadmins end up having to refuse requests and cajole developers into only keeping 3 days of logs instead of 7 to free up disk space. Before you know it, the bosses are hearing bad feedback about the sysadmins...

… and somebody gets the bright idea to replace the sysadmins with “managed cloud” and S3 file storage, leaving the sticker price as a “digital transformation” cost until they can work out the cross-org billing using an app someone built in their spare time to read itemized bills and re-bill internal budget numbers for their fair share of resources?

To complete the story here, the app doesn't work because dependencies have changed in the meantime, so everything is tracked on multiple giant spreadsheets.

That internal budgeting app isn't a top priority because it isn't user facing. The company has enough interns in accounting with Excel experience and one of them knows macros and Access (or PowerApps, or for some horrifying reason, VB6). Of course their math is wrong and they don't know anything about the software they are budgeting across departments and it still just defaults to just bucketing everything as "unclassifiable overhead" rather than revenue departments, but now its in an Excel macro spaghetti ball black box so it is less obvious, and by the time scale up gets out of hand for Excel/Access/PowerApps/VB6 and programmers are actually forced to be assigned to look at the spaghetti ball, because the business might finally collapse at that scale, all of the C-Suite are so used to seeing the reports and the numbers the way they are and programmers aren't as smart as accountants when money is involved and should recreate the system exactly as it was rather than implement improvements, such as say domain expertise of software projects and their revenue models.

Not that I've bitterly seen multiple versions of that in my career or anything, this is still just purely hypothetical complaints department, eh?

> In 20 years and several different companies I have always heard this but never agreed with it.

Do you mean your companies didn't act like maintenance was last on the list, you didn't agree with descriptions that said they would?

Or they indeed did, you just didn't agree this was appropriate, you thought they were acting inappropriately?

Because you seem to be describing environments where indeed maintenance was not valued by the business -- you just didn't like it. So to "say maintenance is not valued by the business" is just to describe reality, like you in fact just did.

I think the common saying that "maintenance is the last on the list" is not meant to be a prescription, advocating this -- it's a description of what seems to happen. Analyzing why and if there's a way for a different approach to be better for the business is not something OP engages in. One would hope so if one, like you, values things working and being high quality... but if very vew companies act this way, there's probably a reason regarding alignent of interests...

I'm fairly certain the GP didn't mean the saying "maintenance is the last on the list" is a prescription. AFAICS their point was simply that it's not even an a valid description of reality; their experience is the opposite.

Both maintenance and testing are not valued by business. Because you cannot sell maintenance to the customer, you only can sell features.

From the developer's point of view maintenance also a thing to avoid. You cannot put a maintenance as a shiny point to your CV. Everyone wants to see your achievements, projects you shipped, and with modern technology, of course.

It depends on your business and your clients. Maintenance in the form of compliance always sells, albeit begrudgingly. If maintaining various compliance requirements is required (like DoD), then maintenance budgets are usually flush with cash.

This is very true. I work in MSP not software dev, but banking/finance clients almost always have budget for regular hardware refresh and premium support agreements. And they fork over tons of cash for security auditing and all the licensing.

> Because you cannot sell maintenance to the customer, you only can sell features.

That does not seem to be true in many B2B areas. Software suppliers are selling maintenance and support contracts to their customers. Think ERP.

Even when a company sells maintenance/support/compliance, the incentive is still to put as few actual development hours into these columns as possible, and to pay as little as possible for those hours.

What is actually being sold is a promise, and that really comes from the sales department, not the engineering department. Once the customer signs the contract, the incentive is to do the minimum possible to keep the promise--or better said, break it infrequently and non-egregiously enough that the customer doesn't churn (or sue). So you'll unfortunately still be viewed as a cost-center at many companies if you're working on this stuff.

You are not considering the power dynamics in B2B. The customers get SLAs in their maintenance and support contracts, including monetary penalties. It is also a repetitive business. Bad experiences actually count.

In my experience, if anything development support/maintenance is delivering too much in many cases, i. e. not limiting themselves to fixing bugs, but enhancing functions on customer request.

Maintenance of your software. Can you sell bug fixing of your software? You can sell new features. Of course you will add a line to the contract about bug fixing, and put few poor souls occasionally to fix issues reported by vip customers, but it is not a selling point.

See my reply to the sibling - in many B2B settings it is really different.

>> Both maintenance and testing are not valued by business.

It depends on the incentives I suppose - if commission and bonuses for sales people comes only from new sales, then sure, maintenance is irrelevant and will be ignored.

>> Because you cannot sell maintenance to the customer, you only can sell features.

No, that's not true at all. If sales people are properly incentivised to sell support contracts (their base salary being a percent of maintenance fee for example) then it will be sold like crazy. I have seen this happen at my company - at one point we did not need new sales to be profitable - just raking support contracts fees was enough to keep up costs and then some.

Support contract does not linked directly to the maintenance of the software you are selling.

More support contract does not mean company will assign more resources into maintenance of software itself.

If you work for people that are only extracting value and are making decision based on next quarter predictions then I can see that.

This is why I do not work for faceless corporation. I deliberately sticked with small lifestyle business that values maintenance as much as new sales (as a matter of fact just this week I was refactoring my own, original piece of code, that its first version is dated by versions control as written 15 years ago and during this whole time there were clients that were paying support fees for it)

You can sell security, support, and compliance and those tend to be tightly related to maintenance. A product hard to maintain becomes a nightmare for any recurring task, security, support and compliance all being examples.

You can also price in the effort of maintenance that needs to be done before adding of a new feature. That may explain it better from the leadership perspective.

I think "maintenance" is too broad a term here.

Keeping the service running to a level that customers demand is a high priority for everyone. Nobody wants to cut SRE to the point outages cause customers to leave.

But I think SRE is closer to "operations" in a traditional company (i.e. unavoidable to provide the service), rather than maintenance (something often deferred as long as possible).

In this framing maintenance is things like tech debt reduction, improving internal tools, experiment iteration time, etc, which is often undervalued relative to product impact IMO.

Well there's "should" and actual reality. The article lays out the latter, pointing out that it's career suicide to go into bucket #3. If you are not an 'up or out' type of person, then maybe it's worth considering spending time in bucket #3.

Of course, software is obsolete the moment it's written, so it could be argued that a lot of people who think they are in #2 are probably in #3 much of the time, spending a small sliver in #2. However, budgets are allocated once a year or maybe a couple more times, so if you are in something that's categorized as #2 when that exercise occurs, you are still in a better place.