15 ms·

Why Do People Neglect Maintenance?

233 points by benbreen 7y ago

adamnemecek 7y ago
No one gets promoted for maintaining things. It's all about delivering new stuff.
- leowoo91 7y ago
  A bit show-off but when you fix an existing issue that no one were able to, that's also delivering.
  - goatinaboat 7y ago
    It will impress your fellow engineers but management won’t care at bonus time. It’s the classic sysadmin’s dilemma: the better you are, the more the organisation takes you for granted.
    - babesh 7y ago
      They will say that you did a good job fixing the issue but most mid level managers won't give you a bonus for that. In fact, in the next breath, they will criticize you for not putting in enough effort into introducing new tech. Fixing the problem is an opportunity cost. The only exception I have seen to the above is if you catch the eye of top level engineering management by your actions. I have seen major problems lingering for years because management's actions have shown that they don't value problems being fixed. Furthermore, when bugs become a priority, the metrics they care about are bug fix time. You are better off not being associated with a difficult bug because it lowers your close rate and lengthens your average time to close bugs. Perverse incentives.
    - emmelaich 7y ago
      This is the key usually; engineers will maintain out of a sense of pride or knowledge that it is actually important. Managers have very little skin in the game to ensure that proper maintenance is done. There are errors on both sides of course. The engineer can miss the forest for the trees.
    - Jach 7y ago
      It might not impact your bonus but it can be added to a doc detailing your accomplishments for justifying a promotion (or at least as a potential topic reminder when interviewing), and can help ensure positive feedback from coworkers when management asks them about you. If there's anything generalizable from the experience ("I once saw something similar and so I did such and such to try to confirm or rule it out") you can sometimes multiply the value to yourself and the company by documenting it, automating it, hosting a lunch and learn type of thing... It all depends of course.. But in any case you have to be the primary person looking out for your own interests since it's the rare manager who will go beyond the minimum guidance, support, and feedback. On the other hand some engineers go too far on self-interest and seemingly start the fires that they then 'heroically' fight to get high level cross-team attention and fast-tracked up the ladder...
    - AnIdiotOnTheNet 7y ago
      Pretty much everybody in this thread is putting the blame on management. Man, no wonder SV is such a shitshow. Either all management is that retarded or all the developers eschew responsibility for their actions.
  - imhoguy 7y ago
    I have noticed the very good maintainers are so indispensable that they hardly get promotion or let go into other stuff. That bound dies with the maintained product. Unfortunatelly for some maintainers it is layoff sentence.
- newnewpdro 7y ago
  That's not really true. Here's an amusing personal anecdote I find relevant, and would enjoy reliving by typing it out: Years ago I had recently started a new job at a clustered database startup as a software engineer. Part of their on-boarding process was to have new hires go through the bug tracker and resolve issues which had been flagged for this purpose. They were supposed to be low-priority low-hanging-fruit type things that jumped all over the code base, good for acquiring some breadth of familiarity while being useful. Well I got bored with that pretty quickly and started looking for the oldest high-priority bugs. To my surprise there were actually quite a number of them, and it wasn't like they were ignored - they had all been touched by many hands but seemed to be difficult to reproduce according to the comments from engineers. One in particular looked especially terrible; the database would close connections as if they were idle during the data import process, causing the import to fail. The import was a very common thing as this product was supposed to replace large, existing FOSS databases, by providing a more scalable clustered solution. Customers would be doing this as the first thing they did with the product, and it's failing! And the bug was over a year old. The thing with import is it's highly optimized because the databases are expected to be huge, so while the logs were showing the connection had been closed due to inactivity, that's very unlikely to be what really happened. But the engineers were all just pointing fingers at the customer side saying there must be a network problem causing the timeout under all the load. But the way the database was implemented was rather complex with cooperatively scheduled coroutines running in their own per-cpu schedulers. It was very Golang-like, except this was not Golang, it was C, and we controlled everything. Knowing that the architecture was cooperatively scheduled, and imports would be causing a whole lot of write-bound work saturating the cluster on the backend, I figured it was probably a starvation problem preventing the coroutine responsible for servicing the sockets from running in a timely fashion, then some idle socket timer would notice and kill it. Some instrumentation code later and a synthetic import running with the cluster on my slow personal laptop (you see I hadn't even gotten a beastly company machine yet, so running a cluster on my old personal machine made it very easy to saturate the local cluster), and I easily reproduced the failure with the instrumentation clearly showing it was indeed due to internal socket-IO coroutine starvation. The way they had the socket-IO getting serviced was only when a given CPU's scheduler was idle. The mostly correct assumption was that there'd frequently be moments where no coroutine was runnable on some CPU, and that would be the best time to service the CPU's sockets. Well, it turns out sometimes that just isn't the case. Coded a trivial fix to have a per-CPU timer service all the local CPU's sockets occasionally, like every five seconds or so, just to prevent the scheduler starvation from triggering a timeout, and submitted it for review as a fix to this ancient, horrible, and embarrassing bug. Well as you can imagine this started a bit of a shitstorm requiring a lot of arguing back and forth and demonstration of the problem, proof of instrumentation showing this was possible, patch actually fixing it, etc. The reason I'm telling this story however is that after the dust settled, and an urgent release was shipped with this fix, I had some new friends in high places at that company. One of the cofounders was in charge of the operations and support department and had been fighting with engineering for ages over this particular bug. Obviously maintenance of neglected but important things can get you promoted. Especially in a smaller company where the important decision makers are watching and still give a fuck.
- wrnr 7y ago
  There is great value is maintaining old software, from an evolutionary perspective it is often the critical systems that have a reason to exist. An organism that has been around for a hundred years has a bigger change of surviving to the next day compared to something born yesterday. Its counter intuitive until you compare the life expectancy of an awk tree and a fruit fly. Most principal software engineers I've known have been with the project since the beginning and live in symbiosis with the project.
  - hoseja 7y ago
    >An organism that has been around for a hundred years has a bigger change of surviving to the next day compared to something born yesterday. This is extremely not true for modern humans. And possibly all humans too. (of course depending on how you define 'organism')
    - jacques_chester 7y ago
      It's a U-shaped mortality curve. More generally, many things show a Pareto power law distribution: if the thing has existed for 10 seconds, expected remaining life is 10 seconds. If it has existed for 2 days, expected remaining life is 2 days. And so on. It shows up in a lot of places.
- bowlich 7y ago
  It, depends. I worked for a company at one point where there was two teams. One team was maintaining the company's main product which was consistently making positive returns to the company year after year. The second team was working on green field projects whose value was entirely speculative. I started on team two, and quickly switched to team one. After a year when the layoffs came, which team got cut?
  - speby 7y ago
    The statement was about getting a promotion, not about avoiding a layoff. I've also seen the opposite of your scenario where a company (almost blindly) cuts staff, including IT/Engineering, and lets go of some of the very key people (sometimes the ONLY people) who have any intricate knowledge of the system in order to maintain it and get caught in all kinds of problems. In one case, I walked into a team that was maintaining a component and they had to claw back the actual laptop from the guy that left and attempt to dig up uncommitted source code that was need to maintain the system.
omeid2 7y ago
The article has some good points but I think the primary issue is that of economics, most organizations are too small for the cultural aspect to override economic concerns. Maintenance doesn't provide immediate economic value, not to customers, not to board meetings, not to developers, not to managers promotions. Developers like myself like it or not, maintenance is a strategic investment driven by long term policy for which many organization have none or can't afford one. Joel Splosky once said "I can’t tell you how many times I’ve been frustrated by programmers with crazy ideas that make sense in code but don’t make sense in capitalism". I think it applies to cost of maintenance fairly reasonably.
- ravenstine 7y ago
  By the time that outstanding tech debt becomes truly problematic, the original authors have most likely moved companies. I think a lot of people know this deep down, which is why so many of them don't go as far to build things on a maintainable way. There's economics for the company, then there's economics for the individual engineer.
  - pytester 7y ago
    Similarly, fixing that technical debt will likely look like pure overhead while the benefit of "other people will finish future features faster and with fewer bugs" gets socialized, realized diffusely and goes largely unrecognized (except, if you're lucky, by the other developers themselves). I learned that one the hard way. Features get priority because features have got visibility. The picture gets even worse when you consider the probability that fixing technical debt will break things.
  - greggman2 7y ago
    Even if they were still at the same company they'd have moved on or been promoted so it's unlikely they'd be asked to maintain. In my own experience though it is one reason I left my last job. 2 year of new dev, 3 years of maintaince with no end in sight. GPU related stuff, new GPUs come out with new drivers all the time. Working around those bugs so the people using my code don't have to deal with them. There is some feeling of reward but it's mostly no fun. Even in my personal projects the more I have the more maintainance piles on. Browsers break stuff or warnings about libraries. Each project adds X more notifications a month. At some point I'll be overwhelmed with maintainance notificications and have no time for anything else unless I ignore them.
baxtr 7y ago
Interestingly this is also related to employee churn. New devs coming to our company usually don’t want to “maintain and fix” the code of others. They’re keen on building new stuff with the newest technology/stack. That adds to the problem.
- TheChaplain 7y ago
  Really? I'm quite to opposite, I love to look through old code, add missing testcases and fix minor issues. It helps me greatly to learn the ins and outs of the software.
  - newnewpdro 7y ago
    There's definitely a preference for writing new code vs. maintaining and extending existing code, especially when it isn't even yours. This is a general human nature thing, it's apparent everywhere in life: "It's more attractive to create new problems than address existing ones"
  - collyw 7y ago
    I don't mind if i am given the opportunity to refactor, but if its just piling more tech debt on top of crap code it gets pretty demotivating.
  - dimitar 7y ago
    What if the code is written in Delphi, committed in SVN and you have to figure out how to build it? True story..
    - hyperman1 7y ago
      Thats pretty tame. I once got a bug like: Some contractor wrote this, got mgmt to get a new, insane deployment procedure scripted and deploy it on completely the wrong server. Some days it produces a report, other days it swallows 16GB and dies. After he left we wrote the contents of his hard drive to this stack of CDs, and they are scratchy enough to have data loss. Of course the prod executable differs from all variants of code found on the CDs. It turns out to be a custom reporting framework for producing exactly 1 report. For extra speed, it starts 100 threads but doesnt have any synchronisation. Which turns out not to matter as they are all fighting for 1 DB connection. You are not allowed to touch prod directly, but have to get some unix guy on the phone so far to recover logs, executable, and config. And as that guy has to support this mess, he hates your guts by association.
lifeisstillgood 7y ago
K.I.S.S As I get older the simpler things seem so much more attractive - for example a recent project is using lists of dicts (python base base base types) because it's simple and easy to think about. It's recently got to the stage where "we should use pandas dataframes" is entering my brain, but it has meant that we focused on the business issues of handling the data not the issues of a large third party code base (even a well run well thought out one) Maintenance starts with not adding complexity to your code
- TeMPOraL 7y ago
  I agree, with a caveat: don't do dumb things performance-wise. The other day I worked with a Lisp code base that used built-in lists for math-heavy code. The result had garbage performance and even looked less readable than proper array-based code that loops on stuff imperatively.
- sgt101 7y ago
  The balance is that a mature, widely used code base should cover corner cases that might rear up and derail homebrew.
29athrowaway 7y ago
Can't maintain them? Don't start them. The company is not your pet project's daddy.
- yjftsjthsd-h 7y ago
  It ... Kinda is? The company started the project long before I showed up, continues to profit from the project, and is absolutely going to reap the rewards of refusing to maintain the stupid thing. This isn't about other people refusing to help with my favorite pet project, it's the company refusing to act and its own best interests.
  - 29athrowaway 7y ago
    Why do many companies have internal projects that do the same as well known open source software? Because someone was bored, or wanted job security, or wanted to feel needed. You should not start a project if a readily available, production-strength alternative exists unless you have a very good reason. Internal projects usually arw underfunded and have bad UI.
unkulunkulu 7y ago
From their front page: > We act > Maintaining self and society through reflection, research, and advocacy. Where is something actual in the list of the ways they act?
- yjftsjthsd-h 7y ago
  Advocacy is an action, and they appear to be driving enough events (per the relevant menu item) to count.
ThalesX 7y ago
Large enterprise solutions usually have maintainers or source a company to do maintaining for them. Startups in today's world - not necessarily 'startups', but also new products - move too fast for maintenance; by the time they pivot, the old stack is easier to replace with whatever new fancy system was sold to stakeholders. Also, most new software churned out today is built from some building blocks, usually community maintained, so no one is going to hire a developer to maintain <insert_fancy_open_source_framework_that_is_heavily_used_and_actively_maintained_by_the_community>.
pontifier 7y ago
I tend to neglect maintenance because it seems like I am always playing "catch up". If something is working fine, then it's not on my radar. Even if problems abound, if the thing will likely get me through my current project, I'll drive that thing into the ground. I drove my last car for over a year with one cylinder not working until someone ran a red light and hit me. Should I have fixed it? Probably, but in hindsight it didn't matter. I have so much coming at me from every direction that maintenance is often a luxury I don't have time for.
- Jach 7y ago
  Everything has economic tradeoffs, triage is needed, but a big problem seems to be a deep set belief that the maintenance you can achieve in x time/budget won't actually pay for itself in fewer issues coming at you later that amount to not paying a cost > x to address. Or similarly is not great enough or frequent enough to create a feedback loop for compounded savings. I don't want to discount just building things better to begin with though. For all the buggy stuff out there limping along there's also plenty of stuff that simply doesn't need maintenance, and another lot of stuff that only needs trivial maintenance.
  - marcosdumay 7y ago
    Well, maintenance can have many different consequences. It can save more than it costs on disaster aversion, it can save more than it costs on small problems, it can save less than it costs on a disaster or small problems. If done earlier it can reduce the cost of future maintenance by much more than it costs, or it can reduce by less. Doing it right on the first place has also all those possibilities, and the risk that you may discover that you spent a lot of time doing the wrong thing completely right.
- jplayer01 7y ago
  I'd say in a case like this, it's an institutional issue. If you aren't getting support from your organization for incentivizing and clearing the path towards maintenance work, then it quite simply isn't your problem anymore.
deleted 7y ago
[deleted]
PeterStuer 7y ago
Pure maintenance is a grind to keep the status-quo. Ideally we would love everything to be maintenance free. There are exceptions to this. This usually occurs when the object or system to maintain evokes an intrinsic positive emotional response as opposed to being something purely functional or utilitarian. Some people love maintaining e.g. old steam engines and keeping them in peak condition. However, even in those cases it usually amounts to select parts of the effort usually involving some physical/sensory satisfaction, while other parts are still considered a chore.
Dowwie 7y ago
Don't forget self maintainence, too! Exercise, eating well, sleeping enough, socialising and having a little fun are often treated as luxuries in many cultures yet are essential to maintaining healthy living.
- maartenh 7y ago
  Especially for us techies who easily live whole days solely in our heads, it's very important to take time and maintain our mind and body. And to keep doing that when there is (perceived) pressure. Don't drop self-maintenance! That's self-sabotage!
- non-entity 7y ago
  > Exercise, eating well, sleeping enough, socialising These all seem incompatible given the work schedules many have
technothrasher 7y ago
"We are unsure how we feel about terms like 'cognitive bias'" What the heck does that mean? They leave a big turd like that on the table and then just move on without elaborating.
jcadam 7y ago
Early in my career, I got stuck doing a lot of software maintenance on legacy systems (I suspect this permanently stunted my professional growth, but this was during the great recession and I took whatever work I could find). It's a hard rut to get out of - I spent a lot of time developing relevant skills in my spare time. Anyway, one place I worked had a 10 page procedure for building the system. It involved running several scripts, logged into 2 or 3 different servers (we were running Solaris 8 - which was already quite old by then) as different users. About half the procedure was written down, the rest was unspoken and passed down via oral tradition. A particularly intelligent and motivated guy once took it upon himself to unravel the whole mess and come up with a sane build solution. Unfortunately, his quest was not approved by management, the time taken away from bug fixing caused him to fall behind on "points" (i.e., number of tickets closed in the bug tracker), and he was laid off. So we stuck to the old system that sort of worked, most of the time. Now, one of the user accounts that was required to build a certain module belonged to a person that no longer worked at the company (let's call him Steve - I don't remember his real name). We were certain there was a permissions or environment issue somewhere, but were unable to track down the specific reason why only Steve's user account could successfully build said module. We were successfully ignoring this obviously absurd situation until we got a new sysadmin.... The new sysadmin was unfortunately a very motivated guy who wanted to set things in order. He reviewed all of the user accounts, noticed "Steve" no longer worked for the company, and deleted his account. We were unable to build until the backup containing Steve's account was restored. We never fixed the FUBARed build procedure, mostly because our customer (this was a defense contract, so the govt was the customer) didn't want to pay for such an effort - every thing we did had to be tied back to a specific req number in our system requirements specification (SRS). Fixing technical debt was not covered in the SRS, so it never got fixed. Eventually I was caught up in a mass layoff and went on to better things :)
- ScottFree 7y ago
  What I got from your story was: 1) Long term software maintenance should not be treated like help desk ticket work nor should it be dumped off on junior programmers. Every company should have at least one guy who enjoys maintaining legacy systems and that should be his sole job. 2) Make sure fixing technical debt is covered in the SRS.
oldandtired 7y ago
The problem of maintenance is not new and is a global problem. Global as in any area that needs maintaining. This effects software systems, hardware systems, legal, political, medical, buildings, equipment, biological, etc., etc,. etc. In the great scheme of things, it is ignored because it is not seen as a "here and now" problem. To see the importance of any form of maintenance in any field, you have to have a long term view of things. You have to understand the "costs" of not doing maintenance for the organisation or system in question. I did not understand this long term view until I worked for someone who did understand and who was able to articulate the "costs" of not doing maintenance. People talk about "tech debt", but are unable to articulate that every system has a cost due to its usage. This is irrespective of whether or not it appears to be bringing income into the organisation or system. This income can be energy, finance (profit) or some other "thing". We live in a world in which everything decays due to ongoing use. In the case of computer systems, this decay can simply be based on changing requirements, bugs, old code running in new environments, etc. If you cannot understand that the "cost" you pay today will effect the "cost" you pay later, then you'll not understand how important the art of maintenance is. The example that jcadam gives about being "stuck" doing maintenance on "legacy" systems is a good example of the lessons about "cost" not being understood by the organisation. From the point of view of maintenance, anything you spend money to keep going is an "asset". It has a function that brings about a benefit for the organisation or system to continue in its existence. So, "legacy" systems are assets, if they need to exist then they need maintenance. However, organisations have a mentality of assigning various areas or systems as "cost" centres and other areas and systems as "profit" centres. This inherently works against both the organisation and the maintenance of its "assets". The idea that some section or system is a "cost" centre is a artifice of the "accountant" mentality. This mentality is very prevalent through most organisations whether very small or very large and all the sizes in-between. Is there anything that can be done about it? If your organisation is controlled by the "accountant" mentality then probably not. If this mentality is not in charge, then you should be able to bring a case for maintenance to those who have the authority to approve it. But, you need to show the benefits both short-term and long-term for doing maintenance for your organisation.
- 0x445442 7y ago
  This is a great comment! From very early in my career I heard this "cost" center classification and I never understood it. Unless a company's hand is dictated by some type of external force such as regulation compliance, why on earth would a company voluntarily keep a "cost" center? Either the ROI is acceptable or it's not.
AlexTWithBeard 7y ago
In day-to-day life a lot of maintenance is neglected because it simply doesn't pay off. My AC installer has recommended annual maintenance. $200 every year for him to come and, essentially, look at the pipes. So far it's been 15 years, no checkups, all is good. If something goes wrong, the $3000 saved so far should be enough for most repairs I can think of.
- adrianpike 7y ago
  > $3000 saved oh man, I had an AC drain backup on a third floor condo once that drained in between the walls in all the units below. the unit owner reeeeeally should have gone with the checkup
  - war1025 7y ago
    It's all wasted money until it's not, right?
- DataGata 7y ago
  You'd guess that there is a trade off between "maintenance" and "insurance" and that a lot of people/corporations go with insurance.
RonaldDR 7y ago
That's an interesting question, because it is clearly a function of culture, a culture of maintaining things. It is a culture that has to be fostered and cultivated and … well … maintained. And just like things that are not maintained, a culture of maintenance will not be maintained either if it is not maintained. The way I see it, maintenance is a function of values and whether one earned what one has; a kind of positive self-fulfilling prophesy. It is why across the board today you can see a crumbling of the maintenance culture at all levels, even if there is clear clustering, from the poor who are given things they don't have to earn anymore and therefore don't maintain anything, to the top ruling class that has never maintained anything and has seen everything, from the most solid castles, to human beings, to ships, to centuries old culture and traditions as totally and utterly disposable if it even slightly stands in their way of achieving their usually megalomanic personal gain; to the common people today that have all manner of things, from phones to telecommunications to television to flight to institutions to cars … literally everything … yet lack any perspective whatsoever on how it was produced, the thousands if not millions of prerequisite steps and failures and attempts it took to produce what they just take for granted. One that does not know the actual value of something will not and cannot ever understand the notion of maintenance. It's a concept that even the ancients knew, yet we have lost in many, if not most ways as people have lost all manner of sense of value that they don't even value money anymore to such a degree that they don't even think of it as anything but a mindless exercise they engage in to do or acquire the thing that stimulates their primitive impulses, whatever those may be. I know some people are trying to push a maintenance culture again, by the stick of enforcement, but reality is that it simply will not work as long as the seemingly lasting negation of scarcity holds. Maybe one day people will realize that all the promises to pay or be paid for the work they did, as embodied in debt, is simply not going to be paid nor can be paid, and it all comes crumbling down and a natural order of scarcity is established that will make people want to maintain things, but until that time, this will only get worse with every passing day as you chuck your $1,000 phone aside very year for a new one without even a second thought.
dmje 7y ago
~grumble~ an SSL cert is up on my list of easy things to maintain ~grumble~
RonaldDR 7y ago
It is disappointing how their post devolves into the same old tar pit of racial intersectionality nonsense that stunts and atrophies the mind. "Concierges paid minimum wage" … many concierges make immense amounts of money for what they do, and often make more than manager of hotels. Most people don't even realize that with overtime most of the hotel desk clerks make more money than salaried managers at hotels. Not even to mention the hotel porters that run the valet, that make immense amounts of money. It's all just the intersectionality nonsense of privileged, sheltered navel gazers that have no idea what goes on outside of their university and screens. I really hope that this intersectionality degeneracy will be killed with fire and relegated to the embarrassing and shameful pile of mass mental abuse and degeneracy that it belongs. One can hope. The worst part about it all is that it just utterly stultifies the mind like any other abused person exhibits, that can only, e.g., reference anything and everything through what their abuser would want or do. But, that was the point after all, creating abused minds that can only think in subservient and submissive ways. It's sad that that abuse of several generations now was allowed to happen.
gerbilly 7y ago
They neglect maintenance because we reward resolving outages and fighting fires more than we do good stewardship. Imagine the following scenario. Acme Co. has some piece of software that is critical to the operation for their business. Dave is in charge of the software system. The software crashes often but Dave is always there to save the day. Dave often has to stay up all night and is seen fixing problems at the final hour. Management takes notice of this and often sends out emails congratulating Dave for his hard work. One day Dave leaves, and is replaced by Amy. Amy takes over the system and slowly and methodically fixes all the bugs that were causing the outages in the software.¹ Over time the code becomes more reliable, till eventually it runs smoothly. Now what would management say if you asked which programmer was better. They'd likely say: "Amy is pretty good, but boy that guy Dave was a real rockstar!" When you reward a behaviour, you will get more of it. If you want software maintenance, then you need to reward it. But often, perversely we reward its opposite. I'm working mostly as an ops person these days, and if I do my job well it makes my contribution look invisible. When things are going right, there won't be anything to notice. 1: In other words, code maintenance.
- BubRoss 7y ago
  Fire fighters are heros but the man who designs a house that never burns down is forgotten.
  - eloisant 7y ago
    ...and in our industry, the fire fighters praised by management are often the one who designed the house like a tinderbox.
- Jtsummers 7y ago
  Relevant paper on this: https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_....
- michannne 7y ago
  Even in the case of a suitable rewards system, one still needs the skill to be able to find and fix bugs that cause systemic issues. Many times, a company opts to get the developers who are good enough - they can build the system, and then they hand it off to some Ops team that maintains, and good luck trying to get them to fix any of the bugs introduced over the course of the project. What should be rewarded is the skill necessary to architect software in such a way that it is easy to maintain. I often say to myself, does this decrease the effort needed by the reporting team to create reports? Does it isolate features and make it easy for devs to find the source of issues and fix them? Is it modular enough that users can expect a quick turnaround time for new features? What I've found is that many developers, even those who believe they should be seniors and above, are unable to think from this perspective, or frequently think it's "impossible" to make software that addresses and solves the issues of all groups. In my experience, it is never impossible, it is all about having the right architecture, which can takes weeks to fully think up and realize, and may still change afterwards, but the design of the software is what I usually choose to reward.
chooseaname 7y ago
Developers who do maintenance are seen (by other, typically greener, developers[0]) as being less skilled than those who work on "new" projects. Personally, I prefer a good mix. I like new development, but I also like helping a business thrive and so I know that maintenance is a part of that. [0] I am not convinced that most managers see it this same way. I think most managers see the people they want on maintenance as some of their most valuable employees.
- naringas 7y ago
  a new project is much easier to do than having to deal with software a few years old created by a parade of a dozen people
auiya 7y ago
It all distills down to poor incentive structures
temporallobe 7y ago
I am dealing with a huge maintenance headache right now, upgrading an entire set of ancient Rails applications from 4.2 to 5.x. It’s a monumental task that involves fixing all the the things, from libraries to controllers to models to rspec tests. We’ve literally waited 5 years to do this. Why? Because pushing out cool new features have greater “business value” than maintenance. It’s all customer-driven.
Pete_D 7y ago
Here's a reason I heard once. I've never heard anyone else mention it, so it's probably BS, maybe a lawyer or accountant can confirm or deny. Developing new features is classed as "productive" or "R&D" or such, which means companies can claim some kind of tech subsidy or tax rebate on employees' wages for time spent doing it. Maintenance tasks like fixing bugs and upgrading servers don't come under this classification, so they can't. The incentives are thus set up for upper management to push against and actively neglect maintenance efforts.
qes 7y ago
Threads like this really help me appreciate my workplace and stay confident in applying pressure to reduce technical debt. I've been the lead at a ~30 person, ~7 dev, ~$5M/yr company for 10 years. As we've grown from < 10 people and 2-3 devs I've had to transition from doing whatever I felt was needed as I found the time to having to get approval across our departments and schedule work across quarters, years, and across a handful or two more people, but I've always been afforded a good deal of trust in my opinion and understanding of the costs and risks of technical debt. I often second-guess my emphasis on improving existing code. To come even remotely close to keeping up takes a lot of developer and QA time and has opportunity cost. Deep down I believe it's vitally important, but there's a nagging voice asking if this is really worth it. Sometimes it turns out not to have been. More often I look back and think that part we made better could've used even more time investment. Personally, I enjoy maintenance work. It's an opportunity to refine and improve ideas I or others had previously. It's less uncertain - the big picture is there, it has history, we've seen how it's expanded and changed over time already, I don't have to try to predict the future as much as I make architectural decisions. Completing a significant refactoring effort is every bit as gratifying to me as launching something new. Staying in one place for a decade has given me opportunity to see through efforts that take years before all the pieces are in place.
rafaelvasco 7y ago
One of the strongest reasons is Minimum Effort Syndrome. People do everything with a focus on having the minimum effort on everything. Maintenance takes work, sweat, burns neurons. The same as admitting that you're wrong takes effort. Giving preference when driving takes effort etc. Of course there's the money factor too.

233 points by benbreen 7y ago

adamnemecek 7y ago

No one gets promoted for maintaining things. It's all about delivering new stuff.

leowoo91 7y ago
A bit show-off but when you fix an existing issue that no one were able to, that's also delivering.
- goatinaboat 7y ago
  It will impress your fellow engineers but management won’t care at bonus time. It’s the classic sysadmin’s dilemma: the better you are, the more the organisation takes you for granted.
  - babesh 7y ago
    They will say that you did a good job fixing the issue but most mid level managers won't give you a bonus for that. In fact, in the next breath, they will criticize you for not putting in enough effort into introducing new tech. Fixing the problem is an opportunity cost. The only exception I have seen to the above is if you catch the eye of top level engineering management by your actions. I have seen major problems lingering for years because management's actions have shown that they don't value problems being fixed. Furthermore, when bugs become a priority, the metrics they care about are bug fix time. You are better off not being associated with a difficult bug because it lowers your close rate and lengthens your average time to close bugs. Perverse incentives.
  - emmelaich 7y ago
    This is the key usually; engineers will maintain out of a sense of pride or knowledge that it is actually important. Managers have very little skin in the game to ensure that proper maintenance is done. There are errors on both sides of course. The engineer can miss the forest for the trees.
  - Jach 7y ago
    It might not impact your bonus but it can be added to a doc detailing your accomplishments for justifying a promotion (or at least as a potential topic reminder when interviewing), and can help ensure positive feedback from coworkers when management asks them about you. If there's anything generalizable from the experience ("I once saw something similar and so I did such and such to try to confirm or rule it out") you can sometimes multiply the value to yourself and the company by documenting it, automating it, hosting a lunch and learn type of thing... It all depends of course.. But in any case you have to be the primary person looking out for your own interests since it's the rare manager who will go beyond the minimum guidance, support, and feedback. On the other hand some engineers go too far on self-interest and seemingly start the fires that they then 'heroically' fight to get high level cross-team attention and fast-tracked up the ladder...
  - AnIdiotOnTheNet 7y ago
    Pretty much everybody in this thread is putting the blame on management. Man, no wonder SV is such a shitshow. Either all management is that retarded or all the developers eschew responsibility for their actions.
- imhoguy 7y ago
  I have noticed the very good maintainers are so indispensable that they hardly get promotion or let go into other stuff. That bound dies with the maintained product. Unfortunatelly for some maintainers it is layoff sentence.
newnewpdro 7y ago
That's not really true. Here's an amusing personal anecdote I find relevant, and would enjoy reliving by typing it out: Years ago I had recently started a new job at a clustered database startup as a software engineer. Part of their on-boarding process was to have new hires go through the bug tracker and resolve issues which had been flagged for this purpose. They were supposed to be low-priority low-hanging-fruit type things that jumped all over the code base, good for acquiring some breadth of familiarity while being useful. Well I got bored with that pretty quickly and started looking for the oldest high-priority bugs. To my surprise there were actually quite a number of them, and it wasn't like they were ignored - they had all been touched by many hands but seemed to be difficult to reproduce according to the comments from engineers. One in particular looked especially terrible; the database would close connections as if they were idle during the data import process, causing the import to fail. The import was a very common thing as this product was supposed to replace large, existing FOSS databases, by providing a more scalable clustered solution. Customers would be doing this as the first thing they did with the product, and it's failing! And the bug was over a year old. The thing with import is it's highly optimized because the databases are expected to be huge, so while the logs were showing the connection had been closed due to inactivity, that's very unlikely to be what really happened. But the engineers were all just pointing fingers at the customer side saying there must be a network problem causing the timeout under all the load. But the way the database was implemented was rather complex with cooperatively scheduled coroutines running in their own per-cpu schedulers. It was very Golang-like, except this was not Golang, it was C, and we controlled everything. Knowing that the architecture was cooperatively scheduled, and imports would be causing a whole lot of write-bound work saturating the cluster on the backend, I figured it was probably a starvation problem preventing the coroutine responsible for servicing the sockets from running in a timely fashion, then some idle socket timer would notice and kill it. Some instrumentation code later and a synthetic import running with the cluster on my slow personal laptop (you see I hadn't even gotten a beastly company machine yet, so running a cluster on my old personal machine made it very easy to saturate the local cluster), and I easily reproduced the failure with the instrumentation clearly showing it was indeed due to internal socket-IO coroutine starvation. The way they had the socket-IO getting serviced was only when a given CPU's scheduler was idle. The mostly correct assumption was that there'd frequently be moments where no coroutine was runnable on some CPU, and that would be the best time to service the CPU's sockets. Well, it turns out sometimes that just isn't the case. Coded a trivial fix to have a per-CPU timer service all the local CPU's sockets occasionally, like every five seconds or so, just to prevent the scheduler starvation from triggering a timeout, and submitted it for review as a fix to this ancient, horrible, and embarrassing bug. Well as you can imagine this started a bit of a shitstorm requiring a lot of arguing back and forth and demonstration of the problem, proof of instrumentation showing this was possible, patch actually fixing it, etc. The reason I'm telling this story however is that after the dust settled, and an urgent release was shipped with this fix, I had some new friends in high places at that company. One of the cofounders was in charge of the operations and support department and had been fighting with engineering for ages over this particular bug. Obviously maintenance of neglected but important things can get you promoted. Especially in a smaller company where the important decision makers are watching and still give a fuck.
wrnr 7y ago
There is great value is maintaining old software, from an evolutionary perspective it is often the critical systems that have a reason to exist. An organism that has been around for a hundred years has a bigger change of surviving to the next day compared to something born yesterday. Its counter intuitive until you compare the life expectancy of an awk tree and a fruit fly. Most principal software engineers I've known have been with the project since the beginning and live in symbiosis with the project.
- hoseja 7y ago
  >An organism that has been around for a hundred years has a bigger change of surviving to the next day compared to something born yesterday. This is extremely not true for modern humans. And possibly all humans too. (of course depending on how you define 'organism')
  - jacques_chester 7y ago
    It's a U-shaped mortality curve. More generally, many things show a Pareto power law distribution: if the thing has existed for 10 seconds, expected remaining life is 10 seconds. If it has existed for 2 days, expected remaining life is 2 days. And so on. It shows up in a lot of places.
bowlich 7y ago
It, depends. I worked for a company at one point where there was two teams. One team was maintaining the company's main product which was consistently making positive returns to the company year after year. The second team was working on green field projects whose value was entirely speculative. I started on team two, and quickly switched to team one. After a year when the layoffs came, which team got cut?
- speby 7y ago
  The statement was about getting a promotion, not about avoiding a layoff. I've also seen the opposite of your scenario where a company (almost blindly) cuts staff, including IT/Engineering, and lets go of some of the very key people (sometimes the ONLY people) who have any intricate knowledge of the system in order to maintain it and get caught in all kinds of problems. In one case, I walked into a team that was maintaining a component and they had to claw back the actual laptop from the guy that left and attempt to dig up uncommitted source code that was need to maintain the system.

omeid2 7y ago

The article has some good points but I think the primary issue is that of economics, most organizations are too small for the cultural aspect to override economic concerns. Maintenance doesn't provide immediate economic value, not to customers, not to board meetings, not to developers, not to managers promotions. Developers like myself like it or not, maintenance is a strategic investment driven by long term policy for which many organization have none or can't afford one. Joel Splosky once said "I can’t tell you how many times I’ve been frustrated by programmers with crazy ideas that make sense in code but don’t make sense in capitalism". I think it applies to cost of maintenance fairly reasonably.

ravenstine 7y ago
By the time that outstanding tech debt becomes truly problematic, the original authors have most likely moved companies. I think a lot of people know this deep down, which is why so many of them don't go as far to build things on a maintainable way. There's economics for the company, then there's economics for the individual engineer.
- pytester 7y ago
  Similarly, fixing that technical debt will likely look like pure overhead while the benefit of "other people will finish future features faster and with fewer bugs" gets socialized, realized diffusely and goes largely unrecognized (except, if you're lucky, by the other developers themselves). I learned that one the hard way. Features get priority because features have got visibility. The picture gets even worse when you consider the probability that fixing technical debt will break things.
- greggman2 7y ago
  Even if they were still at the same company they'd have moved on or been promoted so it's unlikely they'd be asked to maintain. In my own experience though it is one reason I left my last job. 2 year of new dev, 3 years of maintaince with no end in sight. GPU related stuff, new GPUs come out with new drivers all the time. Working around those bugs so the people using my code don't have to deal with them. There is some feeling of reward but it's mostly no fun. Even in my personal projects the more I have the more maintainance piles on. Browsers break stuff or warnings about libraries. Each project adds X more notifications a month. At some point I'll be overwhelmed with maintainance notificications and have no time for anything else unless I ignore them.

baxtr 7y ago

Interestingly this is also related to employee churn. New devs coming to our company usually don’t want to “maintain and fix” the code of others. They’re keen on building new stuff with the newest technology/stack. That adds to the problem.

TheChaplain 7y ago
Really? I'm quite to opposite, I love to look through old code, add missing testcases and fix minor issues. It helps me greatly to learn the ins and outs of the software.
- newnewpdro 7y ago
  There's definitely a preference for writing new code vs. maintaining and extending existing code, especially when it isn't even yours. This is a general human nature thing, it's apparent everywhere in life: "It's more attractive to create new problems than address existing ones"
- collyw 7y ago
  I don't mind if i am given the opportunity to refactor, but if its just piling more tech debt on top of crap code it gets pretty demotivating.
- dimitar 7y ago
  What if the code is written in Delphi, committed in SVN and you have to figure out how to build it? True story..
  - hyperman1 7y ago
    Thats pretty tame. I once got a bug like: Some contractor wrote this, got mgmt to get a new, insane deployment procedure scripted and deploy it on completely the wrong server. Some days it produces a report, other days it swallows 16GB and dies. After he left we wrote the contents of his hard drive to this stack of CDs, and they are scratchy enough to have data loss. Of course the prod executable differs from all variants of code found on the CDs. It turns out to be a custom reporting framework for producing exactly 1 report. For extra speed, it starts 100 threads but doesnt have any synchronisation. Which turns out not to matter as they are all fighting for 1 DB connection. You are not allowed to touch prod directly, but have to get some unix guy on the phone so far to recover logs, executable, and config. And as that guy has to support this mess, he hates your guts by association.

lifeisstillgood 7y ago

K.I.S.S As I get older the simpler things seem so much more attractive - for example a recent project is using lists of dicts (python base base base types) because it's simple and easy to think about. It's recently got to the stage where "we should use pandas dataframes" is entering my brain, but it has meant that we focused on the business issues of handling the data not the issues of a large third party code base (even a well run well thought out one) Maintenance starts with not adding complexity to your code

TeMPOraL 7y ago
I agree, with a caveat: don't do dumb things performance-wise. The other day I worked with a Lisp code base that used built-in lists for math-heavy code. The result had garbage performance and even looked less readable than proper array-based code that loops on stuff imperatively.
sgt101 7y ago
The balance is that a mature, widely used code base should cover corner cases that might rear up and derail homebrew.

29athrowaway 7y ago

Can't maintain them? Don't start them. The company is not your pet project's daddy.

yjftsjthsd-h 7y ago
It ... Kinda is? The company started the project long before I showed up, continues to profit from the project, and is absolutely going to reap the rewards of refusing to maintain the stupid thing. This isn't about other people refusing to help with my favorite pet project, it's the company refusing to act and its own best interests.
- 29athrowaway 7y ago
  Why do many companies have internal projects that do the same as well known open source software? Because someone was bored, or wanted job security, or wanted to feel needed. You should not start a project if a readily available, production-strength alternative exists unless you have a very good reason. Internal projects usually arw underfunded and have bad UI.

unkulunkulu 7y ago

From their front page: > We act > Maintaining self and society through reflection, research, and advocacy. Where is something actual in the list of the ways they act?

yjftsjthsd-h 7y ago
Advocacy is an action, and they appear to be driving enough events (per the relevant menu item) to count.

ThalesX 7y ago

Large enterprise solutions usually have maintainers or source a company to do maintaining for them. Startups in today's world - not necessarily 'startups', but also new products - move too fast for maintenance; by the time they pivot, the old stack is easier to replace with whatever new fancy system was sold to stakeholders. Also, most new software churned out today is built from some building blocks, usually community maintained, so no one is going to hire a developer to maintain <insert_fancy_open_source_framework_that_is_heavily_used_and_actively_maintained_by_the_community>.

pontifier 7y ago

I tend to neglect maintenance because it seems like I am always playing "catch up". If something is working fine, then it's not on my radar. Even if problems abound, if the thing will likely get me through my current project, I'll drive that thing into the ground. I drove my last car for over a year with one cylinder not working until someone ran a red light and hit me. Should I have fixed it? Probably, but in hindsight it didn't matter. I have so much coming at me from every direction that maintenance is often a luxury I don't have time for.

Jach 7y ago
Everything has economic tradeoffs, triage is needed, but a big problem seems to be a deep set belief that the maintenance you can achieve in x time/budget won't actually pay for itself in fewer issues coming at you later that amount to not paying a cost > x to address. Or similarly is not great enough or frequent enough to create a feedback loop for compounded savings. I don't want to discount just building things better to begin with though. For all the buggy stuff out there limping along there's also plenty of stuff that simply doesn't need maintenance, and another lot of stuff that only needs trivial maintenance.
- marcosdumay 7y ago
  Well, maintenance can have many different consequences. It can save more than it costs on disaster aversion, it can save more than it costs on small problems, it can save less than it costs on a disaster or small problems. If done earlier it can reduce the cost of future maintenance by much more than it costs, or it can reduce by less. Doing it right on the first place has also all those possibilities, and the risk that you may discover that you spent a lot of time doing the wrong thing completely right.
jplayer01 7y ago
I'd say in a case like this, it's an institutional issue. If you aren't getting support from your organization for incentivizing and clearing the path towards maintenance work, then it quite simply isn't your problem anymore.

deleted 7y ago

[deleted]

PeterStuer 7y ago

Pure maintenance is a grind to keep the status-quo. Ideally we would love everything to be maintenance free. There are exceptions to this. This usually occurs when the object or system to maintain evokes an intrinsic positive emotional response as opposed to being something purely functional or utilitarian. Some people love maintaining e.g. old steam engines and keeping them in peak condition. However, even in those cases it usually amounts to select parts of the effort usually involving some physical/sensory satisfaction, while other parts are still considered a chore.

Dowwie 7y ago

Don't forget self maintainence, too! Exercise, eating well, sleeping enough, socialising and having a little fun are often treated as luxuries in many cultures yet are essential to maintaining healthy living.

maartenh 7y ago
Especially for us techies who easily live whole days solely in our heads, it's very important to take time and maintain our mind and body. And to keep doing that when there is (perceived) pressure. Don't drop self-maintenance! That's self-sabotage!
non-entity 7y ago
> Exercise, eating well, sleeping enough, socialising These all seem incompatible given the work schedules many have

technothrasher 7y ago

"We are unsure how we feel about terms like 'cognitive bias'" What the heck does that mean? They leave a big turd like that on the table and then just move on without elaborating.

jcadam 7y ago

Early in my career, I got stuck doing a lot of software maintenance on legacy systems (I suspect this permanently stunted my professional growth, but this was during the great recession and I took whatever work I could find). It's a hard rut to get out of - I spent a lot of time developing relevant skills in my spare time. Anyway, one place I worked had a 10 page procedure for building the system. It involved running several scripts, logged into 2 or 3 different servers (we were running Solaris 8 - which was already quite old by then) as different users. About half the procedure was written down, the rest was unspoken and passed down via oral tradition. A particularly intelligent and motivated guy once took it upon himself to unravel the whole mess and come up with a sane build solution. Unfortunately, his quest was not approved by management, the time taken away from bug fixing caused him to fall behind on "points" (i.e., number of tickets closed in the bug tracker), and he was laid off. So we stuck to the old system that sort of worked, most of the time. Now, one of the user accounts that was required to build a certain module belonged to a person that no longer worked at the company (let's call him Steve - I don't remember his real name). We were certain there was a permissions or environment issue somewhere, but were unable to track down the specific reason why only Steve's user account could successfully build said module. We were successfully ignoring this obviously absurd situation until we got a new sysadmin.... The new sysadmin was unfortunately a very motivated guy who wanted to set things in order. He reviewed all of the user accounts, noticed "Steve" no longer worked for the company, and deleted his account. We were unable to build until the backup containing Steve's account was restored. We never fixed the FUBARed build procedure, mostly because our customer (this was a defense contract, so the govt was the customer) didn't want to pay for such an effort - every thing we did had to be tied back to a specific req number in our system requirements specification (SRS). Fixing technical debt was not covered in the SRS, so it never got fixed. Eventually I was caught up in a mass layoff and went on to better things :)

ScottFree 7y ago
What I got from your story was: 1) Long term software maintenance should not be treated like help desk ticket work nor should it be dumped off on junior programmers. Every company should have at least one guy who enjoys maintaining legacy systems and that should be his sole job. 2) Make sure fixing technical debt is covered in the SRS.

oldandtired 7y ago

The problem of maintenance is not new and is a global problem. Global as in any area that needs maintaining. This effects software systems, hardware systems, legal, political, medical, buildings, equipment, biological, etc., etc,. etc. In the great scheme of things, it is ignored because it is not seen as a "here and now" problem. To see the importance of any form of maintenance in any field, you have to have a long term view of things. You have to understand the "costs" of not doing maintenance for the organisation or system in question. I did not understand this long term view until I worked for someone who did understand and who was able to articulate the "costs" of not doing maintenance. People talk about "tech debt", but are unable to articulate that every system has a cost due to its usage. This is irrespective of whether or not it appears to be bringing income into the organisation or system. This income can be energy, finance (profit) or some other "thing". We live in a world in which everything decays due to ongoing use. In the case of computer systems, this decay can simply be based on changing requirements, bugs, old code running in new environments, etc. If you cannot understand that the "cost" you pay today will effect the "cost" you pay later, then you'll not understand how important the art of maintenance is. The example that jcadam gives about being "stuck" doing maintenance on "legacy" systems is a good example of the lessons about "cost" not being understood by the organisation. From the point of view of maintenance, anything you spend money to keep going is an "asset". It has a function that brings about a benefit for the organisation or system to continue in its existence. So, "legacy" systems are assets, if they need to exist then they need maintenance. However, organisations have a mentality of assigning various areas or systems as "cost" centres and other areas and systems as "profit" centres. This inherently works against both the organisation and the maintenance of its "assets". The idea that some section or system is a "cost" centre is a artifice of the "accountant" mentality. This mentality is very prevalent through most organisations whether very small or very large and all the sizes in-between. Is there anything that can be done about it? If your organisation is controlled by the "accountant" mentality then probably not. If this mentality is not in charge, then you should be able to bring a case for maintenance to those who have the authority to approve it. But, you need to show the benefits both short-term and long-term for doing maintenance for your organisation.

0x445442 7y ago
This is a great comment! From very early in my career I heard this "cost" center classification and I never understood it. Unless a company's hand is dictated by some type of external force such as regulation compliance, why on earth would a company voluntarily keep a "cost" center? Either the ROI is acceptable or it's not.

AlexTWithBeard 7y ago

In day-to-day life a lot of maintenance is neglected because it simply doesn't pay off. My AC installer has recommended annual maintenance. $200 every year for him to come and, essentially, look at the pipes. So far it's been 15 years, no checkups, all is good. If something goes wrong, the $3000 saved so far should be enough for most repairs I can think of.

adrianpike 7y ago
> $3000 saved oh man, I had an AC drain backup on a third floor condo once that drained in between the walls in all the units below. the unit owner reeeeeally should have gone with the checkup
- war1025 7y ago
  It's all wasted money until it's not, right?
DataGata 7y ago
You'd guess that there is a trade off between "maintenance" and "insurance" and that a lot of people/corporations go with insurance.

RonaldDR 7y ago

That's an interesting question, because it is clearly a function of culture, a culture of maintaining things. It is a culture that has to be fostered and cultivated and … well … maintained. And just like things that are not maintained, a culture of maintenance will not be maintained either if it is not maintained. The way I see it, maintenance is a function of values and whether one earned what one has; a kind of positive self-fulfilling prophesy. It is why across the board today you can see a crumbling of the maintenance culture at all levels, even if there is clear clustering, from the poor who are given things they don't have to earn anymore and therefore don't maintain anything, to the top ruling class that has never maintained anything and has seen everything, from the most solid castles, to human beings, to ships, to centuries old culture and traditions as totally and utterly disposable if it even slightly stands in their way of achieving their usually megalomanic personal gain; to the common people today that have all manner of things, from phones to telecommunications to television to flight to institutions to cars … literally everything … yet lack any perspective whatsoever on how it was produced, the thousands if not millions of prerequisite steps and failures and attempts it took to produce what they just take for granted. One that does not know the actual value of something will not and cannot ever understand the notion of maintenance. It's a concept that even the ancients knew, yet we have lost in many, if not most ways as people have lost all manner of sense of value that they don't even value money anymore to such a degree that they don't even think of it as anything but a mindless exercise they engage in to do or acquire the thing that stimulates their primitive impulses, whatever those may be. I know some people are trying to push a maintenance culture again, by the stick of enforcement, but reality is that it simply will not work as long as the seemingly lasting negation of scarcity holds. Maybe one day people will realize that all the promises to pay or be paid for the work they did, as embodied in debt, is simply not going to be paid nor can be paid, and it all comes crumbling down and a natural order of scarcity is established that will make people want to maintain things, but until that time, this will only get worse with every passing day as you chuck your $1,000 phone aside very year for a new one without even a second thought.

dmje 7y ago

~grumble~ an SSL cert is up on my list of easy things to maintain ~grumble~

RonaldDR 7y ago

It is disappointing how their post devolves into the same old tar pit of racial intersectionality nonsense that stunts and atrophies the mind. "Concierges paid minimum wage" … many concierges make immense amounts of money for what they do, and often make more than manager of hotels. Most people don't even realize that with overtime most of the hotel desk clerks make more money than salaried managers at hotels. Not even to mention the hotel porters that run the valet, that make immense amounts of money. It's all just the intersectionality nonsense of privileged, sheltered navel gazers that have no idea what goes on outside of their university and screens. I really hope that this intersectionality degeneracy will be killed with fire and relegated to the embarrassing and shameful pile of mass mental abuse and degeneracy that it belongs. One can hope. The worst part about it all is that it just utterly stultifies the mind like any other abused person exhibits, that can only, e.g., reference anything and everything through what their abuser would want or do. But, that was the point after all, creating abused minds that can only think in subservient and submissive ways. It's sad that that abuse of several generations now was allowed to happen.

gerbilly 7y ago

They neglect maintenance because we reward resolving outages and fighting fires more than we do good stewardship. Imagine the following scenario. Acme Co. has some piece of software that is critical to the operation for their business. Dave is in charge of the software system. The software crashes often but Dave is always there to save the day. Dave often has to stay up all night and is seen fixing problems at the final hour. Management takes notice of this and often sends out emails congratulating Dave for his hard work. One day Dave leaves, and is replaced by Amy. Amy takes over the system and slowly and methodically fixes all the bugs that were causing the outages in the software.¹ Over time the code becomes more reliable, till eventually it runs smoothly. Now what would management say if you asked which programmer was better. They'd likely say: "Amy is pretty good, but boy that guy Dave was a real rockstar!" When you reward a behaviour, you will get more of it. If you want software maintenance, then you need to reward it. But often, perversely we reward its opposite. I'm working mostly as an ops person these days, and if I do my job well it makes my contribution look invisible. When things are going right, there won't be anything to notice. 1: In other words, code maintenance.

BubRoss 7y ago
Fire fighters are heros but the man who designs a house that never burns down is forgotten.
- eloisant 7y ago
  ...and in our industry, the fire fighters praised by management are often the one who designed the house like a tinderbox.
Jtsummers 7y ago
Relevant paper on this: https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_....
michannne 7y ago
Even in the case of a suitable rewards system, one still needs the skill to be able to find and fix bugs that cause systemic issues. Many times, a company opts to get the developers who are good enough - they can build the system, and then they hand it off to some Ops team that maintains, and good luck trying to get them to fix any of the bugs introduced over the course of the project. What should be rewarded is the skill necessary to architect software in such a way that it is easy to maintain. I often say to myself, does this decrease the effort needed by the reporting team to create reports? Does it isolate features and make it easy for devs to find the source of issues and fix them? Is it modular enough that users can expect a quick turnaround time for new features? What I've found is that many developers, even those who believe they should be seniors and above, are unable to think from this perspective, or frequently think it's "impossible" to make software that addresses and solves the issues of all groups. In my experience, it is never impossible, it is all about having the right architecture, which can takes weeks to fully think up and realize, and may still change afterwards, but the design of the software is what I usually choose to reward.

chooseaname 7y ago

Developers who do maintenance are seen (by other, typically greener, developers[0]) as being less skilled than those who work on "new" projects. Personally, I prefer a good mix. I like new development, but I also like helping a business thrive and so I know that maintenance is a part of that. [0] I am not convinced that most managers see it this same way. I think most managers see the people they want on maintenance as some of their most valuable employees.

naringas 7y ago
a new project is much easier to do than having to deal with software a few years old created by a parade of a dozen people

auiya 7y ago

It all distills down to poor incentive structures

temporallobe 7y ago

I am dealing with a huge maintenance headache right now, upgrading an entire set of ancient Rails applications from 4.2 to 5.x. It’s a monumental task that involves fixing all the the things, from libraries to controllers to models to rspec tests. We’ve literally waited 5 years to do this. Why? Because pushing out cool new features have greater “business value” than maintenance. It’s all customer-driven.

Pete_D 7y ago

Here's a reason I heard once. I've never heard anyone else mention it, so it's probably BS, maybe a lawyer or accountant can confirm or deny. Developing new features is classed as "productive" or "R&D" or such, which means companies can claim some kind of tech subsidy or tax rebate on employees' wages for time spent doing it. Maintenance tasks like fixing bugs and upgrading servers don't come under this classification, so they can't. The incentives are thus set up for upper management to push against and actively neglect maintenance efforts.

qes 7y ago

Threads like this really help me appreciate my workplace and stay confident in applying pressure to reduce technical debt. I've been the lead at a ~30 person, ~7 dev, ~$5M/yr company for 10 years. As we've grown from < 10 people and 2-3 devs I've had to transition from doing whatever I felt was needed as I found the time to having to get approval across our departments and schedule work across quarters, years, and across a handful or two more people, but I've always been afforded a good deal of trust in my opinion and understanding of the costs and risks of technical debt. I often second-guess my emphasis on improving existing code. To come even remotely close to keeping up takes a lot of developer and QA time and has opportunity cost. Deep down I believe it's vitally important, but there's a nagging voice asking if this is really worth it. Sometimes it turns out not to have been. More often I look back and think that part we made better could've used even more time investment. Personally, I enjoy maintenance work. It's an opportunity to refine and improve ideas I or others had previously. It's less uncertain - the big picture is there, it has history, we've seen how it's expanded and changed over time already, I don't have to try to predict the future as much as I make architectural decisions. Completing a significant refactoring effort is every bit as gratifying to me as launching something new. Staying in one place for a decade has given me opportunity to see through efforts that take years before all the pieces are in place.

rafaelvasco 7y ago

One of the strongest reasons is Minimum Effort Syndrome. People do everything with a focus on having the minimum effort on everything. Maintenance takes work, sweat, burns neurons. The same as admitting that you're wrong takes effort. Giving preference when driving takes effort etc. Of course there's the money factor too.