12 ms·

Most technical problems are people problems

• danjl 11mo ago
  There are plenty of actual "technical problems" that have nothing whatsoever to do with "technical debt".
  • liampulles 11mo ago
    The title could maybe be more accurate if it read "Most Technical Problems IN BUSINESS Are Really People Problems", though I guess its less punchy.
    • danjl 11mo ago
      Or, perhaps "Technical Debt Is Really a People Problem".
• N_Lens 11mo ago
  Isn't this generally the case across all sectors and industries? We have the technology today to create a post scarcity utopia, to reverse climate change, to restore the biosphere. The fact that none of that happens is a people problem, a political problem, a spiritual problem, more so than any technological barrier.
  • roxolotl 11mo ago
    Yea this is true of virtually all problems today. It's one of the blind spots of the AI acceleration crowd. Cancer vaccine discovered by GPT-6? You still have to convince people it's safe. Fusion reactor modeled by Gemini? Convince people it's not that kind of nuclear power. Global Engineering solution for climate change? Well it might look like chemtrails but it's not. Implementation of all of these things in a society is always going to be hard. I think this is a large factor in the turn towards more authoritarian tendencies in the Silicon Valley elites. They spent the 2000s and 2010s as a bit more utopian and laissez faire and saw it got them almost nowhere because of technology doesn't solve people problems.
• zaphar 11mo ago
  I think I'm mostly of the opinion these days that there is no such thing as an "outdated technology". There are technologies that are no longer fit for purpose but that is almost never because of their age. It nearly always because of one of as examples: Needing to run in an environment it can't support, Having bugs that are not getting fixed/no longer maintained, Missing features necessary to solve new problems or add new features, Hitting scale limits. Outdated may sometimes be a euphemism for one of the above but usually when I see it in a discussion it just means "old" or "out of fashion" instead.
  • amonith 11mo ago
    I'd also add "there are almost no developers using it on the job market" to the list why some technologies are no longer fit for purpose. It's a major one. Sort of tied to the ecosystem (no devs - not many things get mantained/created).
    • zaphar 11mo ago
      I do think that holds more water than just "It's old". However for pretty much any dev I would hire for a job they can get to grips with a technology that's older pretty quickly. Where it does get dicey is when good dev just refuses to work with it. For those devs, I think, when they hold that opinion it typically means one of those other reasons is behind their refusal.
      • pixl97 11mo ago
        >one of those other reasons is behind their refusal. I mean, one of those reasons is "When I leave this job will I be able to get another job" is a huge deeply life affecting one. If you want me to work on COBOL from 1988 then you've limited my work prospects to one of a very few employers in the country at a very specific pay range. If I instead tell you to eat a fat one and go with $language_de_jour the number of employers and potential salary range is much, much larger.
        • zaphar 11mo ago
• anonu 11mo ago
  > Most Technical Problems Are Really People Problems The irony is that this is a classic engineer's take on the root cause of technical debt. Engineers are happy to be heads-down building. But when you get to a team size >1, you actually need to communicate - and ideally not just through a kanban board.
  • chasd00 11mo ago
    Im a software engineer but have been around the block enough times that I now lead large teams. It annoys me a little when people here talk about how worthless management is. I just want everyone to know that good management is very hard, way harder than anything I’ve ever faced in software development. It’s subjective, non deterministic, all the things digital logic is not. It’s very hard which is why bad management is so common.
    • bsoles 11mo ago
      > It annoys me a little when people here talk about how worthless management is. I just want everyone to know that good management is very hard, ... People talk about how worthless management is, because most management is not good and most "managers" are worthless. Promotion to your level of incompetence is a real thing in tech management circles.
    • 9rx 11mo ago
      > It annoys me a little when people here talk about how worthless management is. In primary function, a good manager is invisible, so it is understandable that it is seen as being worthless. But in secondary function only a bad manager keeps themselves invisible. A good manager will stand up at stand up and tell about what they've been working on. If you are not communicating exactly what you are doing to everyone else, you've screwed up horribly. > way harder than anything I’ve ever faced in software development. To be fair, you can say that about every job in existence that isn't software development. There is nothing hard about software development.
  • fogleman 11mo ago
    Yes, you are describing a "people problem"...
• IAmBroom 11mo ago
  Reading the article, I'll note the author has chosen to format hyperlinks with dark grey font on a black background. It comes as no surprise that a worker unit who makes this conscious decision might have problems interfacing with a Homo sapiens unit.
• quadrifoliate 11mo ago
  > Most technical problems are really people problems. Think about it. Why does technical debt exist? Because requirements weren't properly clarified before work began. Because a salesperson promised an unrealistic deadline to a customer. Because a developer chose an outdated technology because it was comfortable. I used to be a "stay out of politics" developer. After a few years in the industry and move to a PM role, I have had the benefit of being a bit more detached. What I noticed was that intra-developer politics are sometimes way more entrenched and stubborn than other areas of the business. Sure, business divisions have infighting and politics but at the end of the day those are tempered by the market. It's far harder to market test Ruby Versus Java in a reasonable manner, especially when you have proponents in both camps singing the praises of their favored technology in a quasi-religious manner. And yes, I have also seen the "Why would I learn anything new, <Technology X> works for me, why would I take the effort to learn a new thing" attitudes in a large number of coworkers, even the younger Gen-Z ones.
  • bpt3 11mo ago
    You need to make people include some sort of objective evidence with their argument, and either have a (hopefully benevolent) dictator solve the "vim vs. emacs" problems or just let people pick their environment and sort out any issues they create themselves. If you're trying to pick a development language by committee, something is already very wrong. That something would be a people problem I suppose (because everything is), but it's really a strategic problem of the business.
• woodylondon 11mo ago
  100% agree. Sadly, I have realised fewer people actually give an F than you realise; for some, it's just a paycheck. I am not sure what has happened over the decades regarding actually being proud of the work you produce. I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down, and so want to make sure you don't end up in that position again. Covers all areas of IT from Cyber, DR, not just software. When I have moved between places, I always try to ensure we have a clear set of guidelines in my initial 90-day plan, but it all comes back to the team. It's been 50/50: some teams are desperate for any change, and others will do everything possible to destroy what you're trying to do. Or you have a leader above who has no idea and goes with the quickest/cheapest option. The trick is to work this out VERY quickly! However, when it does go really wrong, I assume most have followed the UK Post Office saga in the UK around the software bug(s) that sent people to prison, suicides, etc. https://en.wikipedia.org/wiki/British_Post_Office_scandal https://en.wikipedia.org/wiki/British_Post_Office_scandal I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect.
  • Noaidi 11mo ago
    > for some, it's just a paycheck. What is wrong with just wanting to work for money? > I am not sure what has happened over the decades regarding actually being proud of the work you produce. Maybe if wages kept up with inflation people would still care. You know, when I was young, I was able to rent an apartment while being a cashier in a grocery store.
    • wccrawford 11mo ago
      Ethically? Nothing. Socially and emotionally? It's brutal. For both the employee and society in general. Spending almost half their waking hours not caring is not good for people.
      • zwnow 11mo ago
        Give us a reason to care. It's that simple.
• jl6 11mo ago
  This is why communication skill is the most important differentiator between a senior dev and a junior dev.
• Noaidi 11mo ago
  People are not problems. This is sociopath talk. This is why they want to replace you with AI, they see you as the problem.
  • magicmicah85 11mo ago
    That's not what the article was about. It's about people failing to communicate.
    • Noaidi 11mo ago
      To me that is not a problem, it is the reality of stuffing people together who have no other bond than it is their place of work. The problem is the system, not the people.
      • magicmicah85 11mo ago
        If you think your only bond to others you work with is your place of employment, you're right.
• woadwarrior01 11mo ago
  Incidentally, in Adlerian psychology; all problems are considered people problems.
• jillesvangurp 11mo ago
  This is a classic engineering take on the problem. It changes when you become a CTO. Because now technical debt is your problem and the choice whether to fix it or not is yours to make. The flip side here is that wrong choices (either way) can be expensive and even kill your company. I've been on both sides. Having to beg a manager to get permission to fix a thing that I thought needed fixing. And now I'm on both sides where as a CTO it's my responsibility to make sure the company delivers working products to customers that are competitive enough that we actually stand a chance to make money. And I build our product too. Two realities: 1) Broken stuff can actually slow down a lot of critical feature development. My attitude as a CTO is that making hard things easier is when things can move forward the fastest. Unblocking progress by addressing the hardest things is valuable. Not all technical debt is created equally. There's a difference between messing with whatever subjective esthetics I might have and shit getting delayed because technical problems are complicating our lives. 2) We're a small company. And the idiot that caused the technical debt is usually me. That's not because I'm bad at what I do but I simply don't get it right 100% of the time. Any product that survives long enough will have issues. And my company is nearly six years old now. The challenge is not that there are issues but prioritizing and dealing with them in a sane way. How I deal with this is very simple. I want to work on new stuff that adds value whenever I can. I'm happy when I can do that and it has a high impact. Whenever some technical debt issue is derailing my plans, I get frustrated and annoyed. And then I sit down and analyze what the worst/hardest thing is that is causing that. And then I fix that. It's ultimately my call. But I can't be doing this all the time. One important CTO level job is to keep the company ready for strategic goals and make sure we are ready for likely future changes. So I look at blocking issues from the point of view of the type of change that they block that I know I will need to do soon. This is hard, nobody will tell me what this is. It's my job to find out and know. But getting this right is the difference between failing or succeeding as a technology company. Another perspective here is that barring any technical moat, a well funded VC-funded team could probably re-create whatever you do in no time at all. If your tech is blocking you from moving ahead, it can be sobering to consider how long it would take a team unburdened by technical debt to catch up with you and do it better. Because, if the answer is "it wouldn't be that hard" you should probably start thinking about abandoning whatever you are trying to fix and maybe rebuilding it better. Because eventually somebody else might do that and beat you. Sometimes deleting code is better than fixing it.
• SilverBirch 11mo ago
  I couldn't disagree more with this description of why technical debt exists and it's a dangerous line of reasoning. Sure, maybe requirements weren't clarified. But often it's impossible to clarify them and you have to build something and even if the requirements were clear to begin with who is to say they'll still be the same by the time you've finished the project let alone 5 years later. Maybe the develop chose a stable and dependable technology because it's battle worn and proven? Maybe the sales person has to manage an impossible situation between an engineering team which can't commit to the time line needed to win the sale? There are lots of good reasons tech debt exists, and it's worrying that this person seems to think that they all boil down to "I don't know how but someone, somewhere, fucked up"
  • bluGill 11mo ago
    The definition of technical debt is the compromises you intentionally make (generally to ship something thus not going bankrupt). Thus by definition nobody made a mistake: this was an intentional decision that was believed correct at the time. You will pay a cost later for the decision, but it is rarely a mistake to make those compromises.
    • pixl97 11mo ago
      Technical debt also includes descriptions of unintentional debt. For example you can 'withdrawal' technical debt from ignorance.
  • uriegas 11mo ago
    As someone else mentioned here: not all technical debt is created equal. I agree, sometimes the problem are changing requirements, etc. But it is also true that there is technical debt caused by developers who don't take the time to properly design features and will simply implement the first thing that came to their minds. I agree with the author, this kind of technical debt is caused by a mediocre attitude which often propagates to all the team if there is no one that calls it out. The more interesting discussion to me is: how do you solve this problem once it exists in a team? I guess there are many approaches, but I tend to think that 'lead by the example' is the best you can do as an engineer, but a top-down approach might work better which is what happened at Microsoft when Satya Nadella became CEO.
• philk10 11mo ago
  Jerry Weinberg, Secrets of Consulting (1985) - "No matter how it looks at first, it's always a people problem." - no matter how technical a problem seems, its root cause always involves people—their choices, communication, management, or skills—making human factors central to any solution, from software development to complex systems
  • mooreds 11mo ago
    Came here to say this. Amazing how timeless his wisdom is.
• jvanderbot 11mo ago
  Peopleware is an excellent book built on this premise. https://www.amazon.com/Peopleware-Productive-Projects-Tom-DeMarco/dp/0932633439 https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...
• munchbunny 11mo ago
  As a data engineer in big tech, the two hardest problems I deal with are: * Conway's law causing multiple different data science toolchains, different philosophies on model training, data handling, schema and protocol, data retention policies, etc. * Coming up with tech solutions to try to mitigate the impact of multiple silos insisting on doing things their own way while also insisting that other silos do it their way because they need to access other silos' data. And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs. As someone who gets to see all of those approaches - most of their approaches are both valid and flawed and often not in the way their leaders think. A few are "it's not going to work" levels of flawed as a result of an architect or leadership lacking operating experience. So yeah, it might look like technical problems on the surface, but it's really people problems.
  • ferguess_k 11mo ago
    I can add so many: - Requirements are rarely clear from the beginning; - We (DE) are not enabling self-service and automation so we are drowned in small requests (add this column for example; - Upstream rarely notify us about the changes so we only know when downstream alerts us. We end up building expensive pipelines to scan and send alerts. Sometimes the cost of alerts > cost of pipeline itself; - We have so many ad-hoc requests that sprint is meaningless. If I were the manager I'd abolish sprint completely; - Shadow knowledge that no one bothered to write down. I tried to write down as much as possible, but there are always more unknowns than knowns; Working in DE definitely gives me enough motivation to teach myself about lower level CS.
    • j_w 11mo ago
      What does DE mean in this context?
      • esafak 11mo ago
        data engineering
      • 11mo ago
• brador 11mo ago
  No doubt the author was richly rewarded for such monumental effort and sleepless nights.
• AbstractH24 11mo ago
  I learn this more and more as my inferiority complex when it comes to code crumbles through the help of AI.
• pjmlp 11mo ago
  Which is why when arguing that technology XYZ succeeded, or failed, one needs to look into the larger picture of the human side regarding the related outcome in the market adoption.
  • another_twist 11mo ago
    Case in point - PyTorch vs Tensorflow. The Pytorch team and Soumith in particular was everywhere. You could ask about it in the forums, Twitter, freaking reddit and there would be an answer.
• dvrp 11mo ago
  Conway’s Law yet again!
• deelayman 11mo ago
  The author suggested that if senior leadership had a development background then tech debt would be easier to get support and resources to deal with. Between the lines I'm reading that the risks are just inherently understood by someone with a tech background. Then the author suggests that senior leadership without a tech background will usually need to be persuaded by a value proposition - the numbers. I'm seeing these as the same thing - the risks of specific tech debt just needs to be understood before it gets addressed. Senior leaders with a development background might be better predictors of the relationship between tech debt and its impact on company finances. Non technical leaders just require an extra translation step to understand the relationship. Then considering that some level of risk is tolerated, and some risk is consciously taken on to achieve things, both might ultimately choose to ignore some tech debt while addressing other bits.
  • another_twist 11mo ago
    The risk of tech debt is marginal cost of adding features goes up as tech debt goes unpaid.
• Scubabear68 11mo ago
  This article resonates strongly. I am consulting right now to a group that has enormous struggles technically, but they are all self-inflicted wounds that come down to people and process. Management claims to want to understand and fix the problem, and their "fixes" reveal the real problems. Fix 1 - schedule a lot of group meetings for twice a week. After week 1, management drops off and fails to show up anymore for most of them. The meetings go off track. The answer? More meetings! We now have that meeting daily. And have even less attendance. Fix 2 - we don't know what people are doing, let's create dashboards. A slapdash, highly incorrect and problematic dashboard is created. It doesn't matter, because none of the managers ever checks the dashboard. The big boss hears we are still behind, and commandeers a random product person to be his admin assistant and has her maintain several spreadsheets in semi-secret tracking everyone's progress. This semi-secret spreadsheet becomes non-secret and people find a million and one problems with it (not surprising as the commandeered admin assistant nee product person was pulling the data from all sorts of random areas with little direction with little coordination with others). We then have the spreadsheet war of various managers having their own spreadsheets. Fix 3 - we are going to have The Source of Truth for product intake and ongoing development, with a number of characteristics (and these are generally not terrible characteristics). These are handed off to a couple of junior people with no experience to implemented with zero feedback. The net result is we still don't have a Source of Truth, but more of an xkcd situation that now we have 4 or 5 sources of truth strung together with scripts, duct tape, bandaids and prayer. This continues on and on over years. Ideas are put forth, some good, some bad, some indifferent, but none of them matter because the leaders lack the ability to followup or demonstrate even basic understanding of what our group actually does. It is truly soul crushing, but in this jobs environment, what are you going to do?
  • slfnflctd 11mo ago
    I worked somewhere with a similarly dysfunctional culture. Peak absurdity, yet you and I have both seen it happen first hand. I wonder how common it is, because it's as ugly as it is mystifying. When management isn't properly engaged, they need to delegate to someone who is. If neither things happen, it's just chaos and angry, ignorant apes making a lot of noise. > in this jobs environment, what are you going to do? I am currently unemployed with a rapidly shrinking cushion, and I'm honestly on the fence as to whether putting up with the above would be better. If there is no hope for improvement, all you're doing is exchanging your mental health for a few more beans.
• another_twist 11mo ago
  Say this in an interview and its a perfect way to fail, even though its true. Its sad how interviewers often take pleasure in pointing out that anything said outside their packets is a signal for lack of technical knowledge. I've been in and passed several tech interviews. I've also interviewed plenty of people, if someone points out the human aspect of a problem, I actually award points. Sad how often I have to fight with my colleagues. "But what about using a message queue.." "Candidate did not use microservices.." "Lacks knowledge of graph databases.." (you know, because I took a training last week ergo it must be the solution).
  • iterance 11mo ago
    Thankfully, we do not have to judge a blog post by its ability to pass muster in technical interviews. :)
  • btreecat 11mo ago
    In my most recent role, everyone interviewing me gave me a thumbs up. Except one engineer. I remembered our conversation well, because it left me a little confused. We were talking about handling large volumes of messages. And when I said "well it really depends on the volume, you could be fine with batch processing in many cases" he jumped on it like I had never heard of a queue. Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues. He flat out rejected the claim (because that didn't fit the current system design). Guess what we're discussing now and have spun up a whole team to complete? Forcing every micro service to use a single API rather than elasticsearch directly, because of scale.
    • munchbunny 11mo ago
      > Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues. There's a small but substantial number of engineers out there who haven't operated at the kinds of scales where hyperscalers' limits become normal architectural problems and don't have the humility to imagine that it could be the case. (e.g. blob stores do in fact have limits you can hit, and when you operate at petabyte scales you have to anticipate in the architecture that you can hit them for even trivial operations.) I also work on petabyte datastores and have encountered a bunch of those engineers over time. To be fair though, that's the small minority of engineers I've encountered, and if it wasn't arguing about the types of scale problems unique to petabyte scales, it'd be about some other nuanced subject matter. It's a humility problem.
• com 11mo ago
  And people problems are almost invariably managent failures
• StanislavPetrov 11mo ago
  PEBCAK
• willguest 11mo ago
  ..and most people problems are communication problems. Calling them 'people problem' is a convenient catch-all that lacks enough nuance to be a useful statement. What constitutes good communication? Are there cross purposes? > Non-technical people do not intuitively understand the level of effort required or the need for tech debt cleanup; it must be communicated effectively by engineering - in both initial estimates & project updates. Unless leadership has an engineering background, the value of the technical debt work likely needs to be quantified and shown as business value. The engineer will typically say that the communication needed is technical, but in fact the language that leadership works with is usually non-technical, so the translation into this field is essential. We do not need more engineers, we need engineer who know how to translate the details. I realise that, here on HN, most will probably take the side of the rational technologist, but this is a self-validating cycle that can identify the issue, but cannot solve it. IMO, we need more generalists that can speak both languages. I have worked hard to try and be that person, but it turns out that almost no-one wants to hire this cross-discipline communicator, so there's a good chance that I'm wrong about all of this.
• jeffheard 11mo ago
  And most people problems are communication problems. Engineers aren't engaged with the product vision or the customer base, and are allowed to silo themselves. Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Sales and CS fail to understand the cost of their promises to individual customers to the timelines of features they're hungry for from the product plan. Goals and metrics for success fail to align. And thus everyone rows in their own direction. The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.
  • arcbyte 11mo ago
    "Better people" solves a lot! But definitely not everything. But a lot!
  • _def 11mo ago
    > Build out what that tech debt is costing the company and the risk it creates How to do that? Genuine question.
    • orangebread 11mo ago
      In my experience development has become too compartmentalized. This is why this game of telephone is so inefficient and frustrating just to implement basic features. The rise of AI actually is also raising (from my observations) the engineer's role to be more of a product owner. I would highly suggest engineers learn basic UI/UX design principles and understand gherkin behavior scenarios as a way to outline or ideate features. It's not too hard to pick up if you've been a developer for awhile, but this is where we are headed.
    • SatvikBeri 11mo ago
• deleted 11mo ago
  [deleted]
• _def 11mo ago
  > the perception that your team is getting a lot done is just as important as getting a lot done. This might be true. But I hate it. I think I should quit software engineering.
• pjmorris 11mo ago
  Jerry Weinberg wrote a number of books to this point, starting with 1971's 'The Psychology of Computer Programming.' Here's what he had to say a decade or so later... "The First Law of Consulting: In spite of what your client may tell you, there’s always a problem. The Second Law of Consulting: No matter how it looks at first, it’s always a people problem." [0] Everything he wrote is worth the time to read. [0] Weinberg, Gerald. "The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully", 1986
  • veryfancy 11mo ago
    Saw this post title and immediately thought of Jerry.
• lupire 11mo ago
  CodingHorror did it 18 years ago. https://blog.codinghorror.com/no-matter-what-they-tell-you-its-a-people-problem/ https://blog.codinghorror.com/no-matter-what-they-tell-you-i...
  • joe_schrag 11mo ago
    And, following the links... apparently Gerald Weinberg in 1985. There is nothing new under the sun, only endless repackagings. :)
• rob_c 11mo ago
  If that's not obvious to you pray you're not over of them... But in seriousness it's management failure to build up debt like that. Either self management, middle management or out of touch management. There's a reason that good managers are needed. And unfortunately most management is dealing with people and/or real-world, not a fixed in stone RFC or list of vendor requirements from legal.
• etamponi 11mo ago
  Technical problems are generated by lack of knowledge. One type of lack of knowledge is interaction with people. You'll never know everything that another person wants to communicate to you because of several reasons. But even in the case of magically fixing people problems - for example, if you are working on a solo project - you will still have technical debt because you will still have lack of knowledge. An abstraction that leaks. A test that doesn't cover all the edge cases. A "simple" function that was not indeed that simple. The mistake you want to avoid at all costs is believing you don't have a knowledge gap. You will always have a knowledge gap. So plan accordingly, make sure you're ready when you will finally discover that gap.
  • intrasight 11mo ago
    > Technical problems are generated by lack of knowledge. Or a lack of action. Tech breaks and you need to take the action of preparing for that.
• ChrisMarshallNY 11mo ago
  I love the header pic. That describes so many projects that I've seen, over the years. One of my first programming projects, was maintaining a 100KLoC+ FORTRAN IV email program, circa 1975. No comments, no subroutines, short, inscrutable, variables, stepped on by dozens of junior programmers, and the big breadwinner for the company. Joy. It was probably the single biggest motivation for my uptight coding style, since. I never want to do to others, what was done to me[0]. [0] https://littlegreenviper.com/miscellany/leaving-a-legacy/ https://littlegreenviper.com/miscellany/leaving-a-legacy/
  • 2b3a51 11mo ago
    "was maintaining a 100KLoC+ FORTRAN IV email program, circa 1975" That sounds challenging, and very early for email. Would I find it in the timeline or was it internal only? https://archive.computerhistory.org/resources/access/text/2022/08/102806104-05-01-acc.pdf https://archive.computerhistory.org/resources/access/text/20...
    • ChrisMarshallNY 11mo ago
      It was basically before Internet email. Proprietary store-and-forward system, run by a BT subsidiary, named Dialcom. Ran on Prime minicomputers. I worked there in 1987. [UPDATED TO ADD] And to add insult to injury, it was all on sub-VGA 300-Baud VT-100 terminals and line printers. I spent a lot of time, staring at blue-striped paper.
      • 2b3a51 11mo ago
        Telecom Gold! Good for you. https://en.wikipedia.org/wiki/Telecom_Gold https://en.wikipedia.org/wiki/Telecom_Gold
        • ChrisMarshallNY 11mo ago
          I still wake up screaming... One of the issues with the system, was it couldn’t generate reliable billing. One customer had been running the system for free, for years, because we couldn’t send them an accurate bill. One look at that bowl of spaghetti, and it’s easy to see why.
• FatherOfCurses 11mo ago
  I worked as an analyst on a team doing a system replacement. The old system assigned work cases out in a plain round robin system - Person 1 got Case 1, Person 2 got Case 2, etc, regardless of what people already had on their plate. The new system looked at a number of factors and assigned a new case to people who had the least amount of overall work in their queue. So if Person 1 had 2 cases and Person 2 had 10, then Person 1 was getting the next case. Management in one division came to us after a while and said the method of assigning cases was broken, and cases were not being assigned out "fairly." They wanted us to implement the old system's round-robin assignment method in the new system. After some investigation I determined that workers had figured out ways to game the system in order to seem more busy than they actually were and therefore receive less new cases. As a result efficient workers who were actually doing their jobs were getting punished with new cases while inefficient workers were getting rewarded. I, another analyst from that division, and my management laid out a very clear case that if employees were not properly handling their cases, and not being monitored on their progress (by all the new monitoring tools the new system provided) then changing the method of distributing cases wouldn't fix the underlying problem. We were overruled and forced to implement the technical solution to the human problem.
  • spongebobstoes 11mo ago
    seems like this was a decision between two technical solutions, not a people problem. one solution had a kind of perverse incentive even without perverse incentive, it seems to be human nature that work expands to fill available time (this is another kind of perverse incentive) maybe best to frame problems of human nature as technical problems. ex, the preferred path should be the easiest path sadly, people do not behave like the utopian ideal
  • _n66o 11mo ago
    [dead]
• kmoser 11mo ago
  Some questionable assumptions here: > The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind. Reasons vary widely. Code can also get calcified because people lack the vision, tech skills, or time/budget to update it. On the opposite side of the spectrum, personality types who do like change sometimes rip out everything out and start from scratch, effectively destroying well written code, which is no better. > Why does technical debt exist? Because requirements weren't properly clarified before work began. Not necessarily: it can also exist because code wasn't well written to begin with, libraries weren't updated to work with OS updates, feature-creep, etc. > In my opinion, anyone above senior engineer level needs to know how to collaborate cross-functionally, regardless of whether they choose a technical or management track. Collaboration is a skill everyone needs, and the ability to explain things to people at other levels shouldn't be limited to senior engineers. Even junior devs would do well to be able to explain things to higher-ups.
  • pixl97 11mo ago
    >Because requirements weren't properly clarified before work began Yea, software is typically way more flexible and fast moving in the real world. At start of project: "We need software with A, B, and C" In middle of project: "Our competitor has released with ABCD and E, and if we don't add at least E we might as well cancel the project" There is also - Our software works 100% fine with what we expected in the field, problem is (new|old) thing showed up and now we have to work around all the bugs in it. Then there is Chesterton's fence. That 'broken old crap' was actually doing something highly specific that calcified into how the customers systems work. People love ripping crap up and changing stuff, until they figure out it just broke their enterprise clients workflow, and that client pays their salary.
• gaigalas 11mo ago
  All problems that concern people are people problems. That's why we don't talk about it. It's like saying all rain is wet. Just assume the other person knows, and avoid one extra people problem.
• amelius 11mo ago
  Yes, we evolved to have people problems. If however, we were more technical about things during the entirety of evolution, we would exclusively have technical problems now. So maybe it is good to start taking the technical angle.
• 0xWTF 11mo ago
  At this point I'm fairly senior and work directly with funding sponsors and requirements owners. The gal who 100% owns the problem, worldwide, says "I need X, how much it going to cost?", while X is a big, hairy ball of wax and I have 18 minutes left in the 30 minute meeting to get as many details as I can while I work up a guesstimate. Because the funding line will be decided by minute 30. They have no idea what's going on technically. But they know where the money is and the words that have to be spoken to certain people to get and defend that money. I have been handed a problem that was estimated to cost $6M and solved it with a text message, in the meeting. Shoulda taken the money. I have also had a project poached from me, watched the new team burn $35M and come out the other end with nothing but bruised egos. The sponsors with the budget are definitely folks who prioritize politics over everything else. They have generally have bachelor's or master's degrees, rarely doctorates. You look at their career and wonder how they got there. Their goal is not mission success. Their goal is the next job. They've been dressing for the next job their whole career. The financial folks are afraid of them, or at least very wary.
• stego-tech 11mo ago
  Post hits the nail on the head. Even the best engineering solutions that closely align to organizational goals will be torpedoed by people at the end of the day, often to preserve their own political power rather than improve the organization or their own working lives. This is why I laugh when I hear someone say tech is a meritocracy. It is if you consider manipulation, exploitation, subterfuge, sabotage, and backstabbing to be of merit; otherwise, there is no meritocracy out here in the real world, not so long as any given individual of power can destroy your career or livelihood over hurt feelings. As much as I’d love everything to be a technical problem to solve, that’s just not reality at the moment. We gotta listen to people beyond our silos and find a way to get them to our side in things if we want to progress forward on something. I’m doing that right now in a company stuck firmly in the 1990s, and it sucks.
• adsharma 11mo ago
  For every person trying to move an old code base from COBOL to Java to remove tech debt, there are an equal number of people who want rewrite a working C++ code base in Rust/Go/Zig. Leaders who know that it's a people problem and who have read the Jerry Weinberg book know both sides of the problem.
• hermitcrab 11mo ago
  Reminds me of the quote attributed to Stalin: "Death solves all problems, no man, no problem."
• sandeepkd 11mo ago
  There is a big and vocal group one who does not believe in the idea of solving the tech debt for couple reasons 1. Solving tech debt is not going to get you promotions and visibility as the article right said there is no visible difference 2. Its going to accrue continuously 3. There is no dedicated role that owns the tech debt so its not really anyones explicit responsibility as a part of job
• dbacar 11mo ago
  In my opinion, people problems is just a subset of communication problems. Communication also involves people not working at the same place (remote), at the same time(remote). Even the gal working next room is a problem, that hinders questions.
• leoc 11mo ago
  It’s the eternal cycle: all social problems really are tech problems in disguise; so it’s unfortunate that all tech problems are social problems in disguise. ;)
• jackfranklyn 11mo ago
  [flagged]
  • joe_schrag 11mo ago
    This is an excellent point. I've also seen scenarios in which the architectural scar is being defended vehemently by an engineer still at the company. In my experience it is someone respected, who is overall a highly competent engineer, and the rest of engineering ends up working around the scar. Thanks for reading!
• liampulles 11mo ago
  I have been a part of a team that actually managed to significantly reduce critical tech debt in its system, to the point of background radiation. I can speculate on what I think were key contributing factors (some of which are just productivity improvements, which meant we had more bandwidth for tech debt): * The team used a monorepo for (nearly) all its code. The upshots of this include the ability to enforce contracts between services all in one commit, the ability to make and review cross-cutting changes all in one PR, the increased flexibility in making large-scale architecture changes, and an easier time making automations and tools which work across the system. * We used Go, which turned out to be a really excellent fit for working within a monorepo and a large-ish codebase. Also, having the Go philosophy to lean back on in a lot of code decisions, which favors a plain and clear style, worked out well (IMO). And its great for making CLI tools, especially ones which need to concurrently chew through a big data dump. * Our team was responsible for integrations, and we took as a first principle that synchronous commands to our API would be the rare exception. Being async-first allowed us to cater for a lot of load by spreading it out over time, rather than scaling up instances (and dealing with synchronization/timing/load explosion issues). * We converted the bulk of our microservices into a stateless monolith. Our scalability did not suffer much, because the final Go container is still just a couple MB, and we can still easily and cheaply scale instances up when we need. But being able to just make and call a function in a domain, rather than making an api and calling another service (and dealing with issues thereof), is so much easier. * Our team was small - for most of when I was involved, it consisted of 3 developers. Its pretty easy to talk about code stuff and make decisions if you only have to discuss it with 2 other people. * All of us developers were open to differing ideas, and generally speaking the person who cared the most about something could go and try it. If it didn't work, there would be no love lost in replacing it later. * We had a relatively simple architecture that was enforced generally but not stringently. What I mean by that is that issues could be identified in code review, but the issue would be a suggestion and not a blocker. Either the person changes it and its fine, or they don't, in which case you could go and change it later if you still really cared about it. * We benefited from having some early high-impact wins in terms of productivity improvements, and we used a lot of the spare sprint time to tackle ongoing tech debt, rather than accelerate feature work (but not totally, the business gets some wins too). * Big tech debt endeavors were discussed and planned in advance with the whole team, and we made dilligent little chips at these problems for months. Once an issue was chipped away enough to not be painful anymore, then it didn't get worked on (getting microservices into the monolith, for example, died down as an issue once we refactored most of them). * Tech debt items were prioritized by a ranked vote made by everyone, using a tool I built: https://github.com/liampulles/go-condorcet https://github.com/liampulles/go-condorcet. This did well to ensure that everyone got the opportunity to have something they cared about, get tackled. Often times our votes were very similar, which means we avoided needless arguments when we actually agreed, and recognized a common understanding. I think this contributed to continued engagement from the team on the whole enterprise. * Our tech stack was boring and reliable, which was basically Postgres, Redis, and NATS. Though NATS did present a few issues in getting the config right (and indeed, its the least boring piece). We also used Kubernetes, which is far from boring, but we benefited from having a few people who really understood it well. * We built a release tool CLI, and built reasonably good general error alerting for our system (based on logs mostly, but with some sentry and infra alerts as well), that made releasing things become easy. This generally increased productivity, but also meant that more releases were small releases, and were easier to revert if there were issues. * We had a fantastic PM, who really partnered with us on the enterprise and worked hard to make our project actually Agile, even though the rest of the business was not technical.
• jibal 11mo ago
  "Most problems resulting from things people do are people problems."
• jama211 11mo ago
  This is why I hate it when people are judged (like the article writer is doing) for doing what their job requires of them and not “taking pride in their work” - the thing is, the workers generally don’t own the work, the business does. If the business wants something a certain way, and if they act to punish you for trying to push back, why fight them? It’s not our company. We’re cogs in a machine, if they treat us like that then what do they expect? This article has a stink of self importance that rubs me the wrong way.
  • squirrellous 11mo ago
    This is painfully clear once you’ve worked in a non-first-world country. Everybody is just working a job.
    • jama211 11mo ago
      Interestingly it became most painfully clear to me once I started working in an office in a developed country. Something about seeing the scale of it all. But I take your point.
• xorvoid 11mo ago
  Ha. At my last job, I observed that we were so good at solving technical problems that we transformed social problems into hard technical problems so we could solve the original song cial problem. It's something like a problem reduction in Algorithmic Complexity Theory. There was perhaps a simpler social-centric solution, but we didn't have a method for solving those...
• jerhewet 11mo ago
  At least the headline makes sense to me. > Most technical problems are people problems Certainly explains Microsoft Teams and Windows 11. [note there is no /s -- it's 100% a people problem, because the wrong people are steering the ship]
• rubyfan 11mo ago
  While I agree with the sentiment one statement jumped out that grinds my gears. >Why does technical debt exist? Because requirements weren't properly clarified before work began. I hate this line of thinking and the expectations that come along with this style of work. The idea that developers need to be spoon fed requirements and only then can they start working because they fundamentally lack an understanding of the desired business outcome and their work output is so valuable that it can’t evolve as their understanding of the problem evolves _is problematic_. To be clear I’m not blaming developers but the style of work that often goes by names like waterfall, agile, SAFE, agile 2.0, transformation, etc. is all hot garbage.
• nrhrjrjrjtntbt 11mo ago
  Feels like beauracracy but a DACI or RFC etc. can help if the culture supports this sort of decision making. You list the options, e.g. A combine codebases, B leave as is. Get comments and look at it logically and come to agreed decision. You have the reason and tradeoffs documented. The discussion may prompt other wider discussions etc. More senior people may spot patterns. E.g. lets not pay down tech debt X because Y is coming. Culturally though if no one cares and most people are happy to manually work through the bugs and hate even discussing it then it may be a bad fit for a developer who cant stand working like that.
• groby_b 11mo ago
  I mean yes, if you waste time on worked that does not bring value, people tend to get cranky. If you then take longer than you said, it's not a mood enhancer. That's not a people problem though. That's failure to recognize that a company pays its employees money to make more money, not to have a pretty code base. Yes, that means communicating the value, but that's not a people problem. That's a skills issue. "anyone above senior engineer level needs to know how to collaborate cross-functionally" If you can't collaborate xfn and deal with other people in general, you are not a senior engineer, despite the title inflation.
• Brysonbw 11mo ago
  100% agree. The coding is straightforward - it's the human factors, context, and data complexities that make things difficult
• chanux 11mo ago
  I'm clearly jaded by my own experience but I feel that there's less and less focus on building and retaining a solid team. People are treated like cogs on a machine and this shape their view of the system in return. It's actually quite awful to work in such an environment.
• dworks 11mo ago
  All product problems are organization problems.
• Darmani 11mo ago
  I can write a similar article that: most people problems are technical problems. This article hits on a pet peeve of mine. Many companies and individuals can benefit from better processes, communication skills, and training. And also people who proclaim "Most technical problems are people problems" and "It's not what you know, it's who you know" are disproportionately those who are attempting to influence others that "My skillset is more valuable than your skillset." The people who believe the opposite are heads-down building. The truth is that nearly all problems are multifactorial and involve long chains of causality. They can be patched at multiple points. And so while there are standard stories about "If you do the 5 Why's and trace back causality, the issue becomes a deeper human problem," you can nearly always do something else and find an alternative technical solution. The standard story goes: "This thing failed because this this other thing crashed, because this thing was misconfigured, because the deployment script was run incorrectly, because no-one trained Bob how to use it." See, the human problem is the deepest one, right? But you can find an alternate technical fix: why was it possible to run the deployment script incorrectly? Or you can ping-pong it back into a technical problem: he wasn't trained because everyone is stressed with no time because things keep breaking because of bad architecture and no CI. So actually the technical problem is deepest. But no, because that only happened because the CEO hired the wrong CTO because he didn't know anyone who could evaluate it properly.... ...which only happened because they didn't use <startup that helps you evaluate engineers> (technical problem) ...which only happened because said startup didn't have good enough marketing (human problem) ...which only happened because they were too slow to build from their own tech debt and didn't have the money (technical problem...) And so on. Ping, pong. The article says: we had too much tech debt because humans weren't trained enough. One can also say: we had too much tech debt because we didn't have good enough linters and clone detectors to keep out the common problems, and also we had made some poor technical choices that required hiring a much larger team to begin with. If you have a pet problem, you can always convince yourself that it's responsible for all woes. That just keeps you from seeing the holistic view and finding the best solution.
• d--b 11mo ago
  Well technical debt is not really a technical problem, it’s a choice. Someone at some point said: ok we’re going to duplicate code, we’ll have a windows version and a Linux version, and yes it’ll be painful - for a while - but at this stage, it is the better option. At some point getting shit done might be more important than getting it right. Whether that is smart or not is a people problem. Working on large legacy codebase is extremely annoying indeed, but sooner or later, in everyone’s career one has to make those sort of tradeoffs, and when that day comes maybe you’ll forgive those who came before you. Edit: I want to add this: Also those tradeoffs are often required because of business problems. It’s difficult to see, 10 years down the road, how shitty the business may have been when those decisions were made. And perhaps, it’s some of those business-driven decisions - like rushing the product out the door no matter what - that kept the company afloat and made it so that you have a job (albeit to fix the mess) today.
• getnormality 11mo ago
  There are other ways to look at it. Back in the old days when computers required lots of planning to program, the technical problem of having a buggy program was also a people problem of not planning carefully enough. But now we have fast computers and cheap storage and version control and autosave and so many other things, such that perfectly conscientious human planning of the activity of programming is no longer necessary. In many cases you can just bang stuff out by trial and error. My point is, we have often discovered technical solutions for things that used to be regarded as people problems. So maybe a lot of things are just problems, which may be solvable through either technical or people means.
• self_awareness 11mo ago
  Nah. > Most technical problems are really people problems. Think about it. Why does technical debt exist? Because requirements weren't properly clarified before work began. Because a salesperson promised an unrealistic deadline to a customer. Because a developer chose an outdated technology because it was comfortable. Because management was too reactive and cancelled a project mid-flight. Because someone's ego wouldn't let them see a better way of doing things. I mean true, technical debt is people's problem. Why it exists? Because there are not enough people in the team. Because they are not skilled enough. Because the devloper has promised they'll finish up the task before Christmas but failed to deliver. I don't really like marketing, but they serve an important function: they convert code to money. Code itself isn't worth anything, only marketed code is worth something. That's why it's so hard to refactor. Also there's this unofficial law in programming: code that is easy to refactor at some point is going to be replaced by code that is hard to refactor. Sometimes people misidentify what exactly is code debt and convert blocks of code that aren't code debt into exactly code debt which is later impossible to remove, because they thought they knew better.
• solatic 11mo ago
  > I had one developer openly tell me, "I don't want to learn anything new." To play Devil's Advocate here, there's a big, big difference between JavaScript-ecosystem-style framework/library/fad-of-the-month where you are nagged on a daily basis that your libraries and tools are out of date, to building everything in Go on the back of the standard library, deploying to some LTS distribution. The benefits of technical stability for product agility are real. Yes, it may mean your codebase is in a subset of C++ and is the domain of a 50+-year-old, genuinely-Senior Engineer who's been writing C++ for more than thirty years, who you will need to sit and negotiate with to make product changes. C'est la vie. Calling that tech debt, in and of itself from the outside, is not really fair, that's ageist. There are precisely two people who can determine whether or not there is technical debt: (a) the lead IC responsible for the codebase, according to their innate understanding of the state of the codebase, (b) the manager who is responsible for the IC who both (1) observes that release agility is at risk and (2) is willing to invest in non-functional work to get future increases to release agility.
• d4rkn0d3z 11mo ago
  And most people problems are math problems.
• dzonga 11mo ago
  what's not spoken in this article is you have people problems in bloated teams. hence the explosion in communication channels & those channels breaking down. you don't have communication problems if say max 3 engineers are working on a product line.
  • about3fitty 11mo ago
    This is underappreciated. The number of individual conversations (edges) possible between n engineers (nodes) does not scale linearly. https://en.wikipedia.org/wiki/Complete_graph https://en.wikipedia.org/wiki/Complete_graph
• DiscourseFan 11mo ago
  I suppose I entered this industry as one of many thrown onto some project and I just happened to be good at what I was doing. But what was more important for my promotions ended up being my ability to work with and train others to do what I was doing, to scale the operations of the business and effectively communicate intent, ideas, and solutions to problems. I attribute this partially to my background in the humanities, and partially to things I learned growing up, in various positions before the one I have now, where I was forced to learn how to work with others in just this way. No matter what, nobody succeeds in any industry without excellent interpersonal skills or at least a bit of cunning. Its very sad to me, as when I was younger I was very idealistic and I wanted to change the world, that’s where I learned to marshall others to support a cause; now, I marshall them to hit project goals. Its all the same, “But where the danger is, also grows the saving power.” (Hölderlin)
• nextworddev 11mo ago
  Most technical problems are job security problems