7 ms·

I have never worked in an environment where new employees didn't show up and declare that the existing infrastructure sucks. Knowing this, I caught myself doin

• PopeOfNope 11y ago
  Notice that nowhere in the article is there any mention of what a good architectural choice is, nor any mention of the perception of debt in relation to the size of the system[0]. My personal experience with architectural choices is that all of them are great early on when the code base is small. As that code base grows, they all suffer under the weight. [0]: 100k-1M is a very large range. Kudos to them for filtering out small code bases, but a graph of these perceptions measured against code size would have been helpful.
  • nernst 11y ago
    (author here) We cross-tabbed system age vs perception of amount of TD. There was a moderate association between older systems (> 6 yrs) and more perceived debt. I did not explicitly look at size as this was not one of the original research questions, but a good point. I suspect older systems will tend to be larger (in the domains we studied, anyway). And your point about arch choices being great "early on" can, I think, be captured in the "system age" variable. I guess I'm trying to think of a system that might be young and yet quite large in LOC.. would be an interesting outlier to look at.
    • PopeOfNope 11y ago
      I guess I'm trying to think of a system that might be young and yet quite large in LOC.. would be an interesting outlier to look at. Take a look at video game companies. They tend to build up a large infrastructure early in the development of a game. Keep up the great work! I love to see scientific research being done on software development. :)
• bsder 11y ago
  In most places I have been, the infrastructure DOES suck. First question: "Backups?" followed by "When was the last time you did a restore?" Second question: "What's your revision control?" For all of my slagging on git and the people who use it, I am thrilled if I hear "CVS" or "Subversion" because it means they're using version control. "git" or "mercurial" tells me I have an team that has some level of clue. Third question: "Build system?" Good luck. Never yet seen it.
  • stephentmcm 11y ago
    You need to look harder then, we tick all three and even use Gitflow. With back ups used all the time for testing live state locally and a CI 1-click (well 5 or 6 actually...) deploy to Test/Stage/Prod.
    • bsder 11y ago
      Congratulations. You're the 1%, you don't need my services. :)
      • eitally 11y ago
        I came from an awful IT environment and even my team met your criteria. I think you might be primarily exposed, due to the nature of your work, to the worst of the worst. We had/have a lot of technical debt, but the architectural ones are the hardest to fix (because they cost real capital). You wouldn't believe how hard it is to get sign off on new servers (at some companies). My team nearly made an executive decision to switch to GCP or AWS just to escape our own internal infrastructure group.
        • GFischer 11y ago
          Believe me, there are 10.000 million dollar non-software companies that barely use version control, and with extremely awful IT departments. And there are companies making a killing selling software to said companies.
      • 11y ago
• gfosco 11y ago
  It just shows how completely subjective it is, and that "technical debt" is becoming an excuse for anything and everything.
  • tracker1 11y ago
    I know someone who says all the time that what they want is "The cheapest, fastest (least time to complete), most predictable thing to get something done" and "that if it needs fixing, it can be done when the customer pays for it" Even green field projects there wind up with significant technical debt in under a year or two.
• pjungwir 11y ago
  As a first-year programmer a project manager said to me, "I've never heard a programmer praise another's code. It's always, 'This is crap!'" So I always try to be slow to criticize. There is a lot of crap, but things might not be as simple as you think. I really believe we should take more time to read and understand before we write. Or think about G.K. Chesterton's fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence You should resist someone who says, "I don't know why this is here, let's get rid of it!" Only get rid of something if you do know why it's there!
  • nothrabannosir 11y ago
    > You should resist someone who says, "I don't know why this is here, let's get rid of it!" Only get rid of something if you do know why it's there! I know this is orthogonal, but please try to avoid these situations by commenting code which people might wonder exactly that of, in the future. :(
    • deleted 11y ago
      [deleted]
    • PJDK 11y ago
      Even better, write a test with a name that describes its functionality.
  • Joky 11y ago
    Oh no, I always get rid of stuff I don't know why it's there. Because if it does not break when I run "make check", it's not covered by the testing and it shouldn't have been there in the first place anyway. And if it had a use for someone, but nobody knows, removing it is also a very efficient way to figure out :)
    • deleted 11y ago
      [deleted]
    • logn 11y ago
• InclinedPlane 11y ago
  It does suck. Most code sucks. We just get used to it. Doesn't mean it doesn't work, doesn't mean it's not valuable. But it still sucks. As for architecture being the biggest technical debt problem that should be obvious. Architecture is often the most difficult thing to change after the fact.
  • jschwartzi 11y ago
    "Good code" is often a euphemism for understandable code.
    • InclinedPlane 11y ago
      Understandability is an important metric for good code (within reason).
• Bahamut 11y ago
  Half of the time, the build system of companies I join is unnecessarily complicated. I often end up simplifying things once I get a handle for how it works, creating nice one command deploys or workflows that don't require chaining multiple things or memorizing a gazillion abstractions. Meanwhile, people often waste lots of times on inefficient build tooling and multiple steps to get to the end goal. None of the companies I have been at created a good model system (although one came close, the employee responsible left due to the startup acting like a consultancy instead of focusing on a quality product) - this has often bit companies hard as data structures start mutating due to changing API & changing requirements, making certain things such as offline caching more difficult. Architectural choice tends to roll into poor time constraints since poor time constraints puts even more pressure on the code base when poor architecture is involved.
• tbrownaw 11y ago
  The reason I bring this up is I am surprised that architectural choice is overwhelmingly the top technical debt concern. That doesn't seem right. I would expect it to be poor code due to time constraints. 1. The system grew alongside the devs' understanding of the problem space. There was never time to change decisions that were later found to be not the best (and the older such a decision is, the harder it is to fix). 2. The problem space changes over time. Either because the outside world changes, or because of scope or scale increases. This means that even good architectural decisions can become bad over time. Isolated pieces of bad code can be fixes when/if they need to be touched for some other reason. Fixing currently-inappropriate architecture takes a bit more effort.
  • shoo 11y ago
    This is very wise. You try to make the best architectural decision that you can at the time, with the knowledge and resources you have available. Time passes and you learn new things -- maybe the problem changes, or your understanding of it improves, or your understanding of alternative implementation strategies improves. For whatever reason, you can now imagine a new architecture that would be superior, if only it were implemented to replace the old architecture. Now you have technical debt. This doesn't necessarily mean that the best decision now is to pay off the debt by reworking the architecture -- that depends upon a cost/benefit/opportunity cost analysis. edit: Tangentially, there's a pretty interesting presentation by Kevlin Henney titled "The Architecture of Uncertainty" [1]. My poor summary: When designing the initial architecture of a system, Kevlin suggests that the team brainstorm to identify which parts of the system have a lot of uncertainty. Each region of uncertainty then becomes a subsystem. Put interfaces between the subsystems that need to be connected. Hopefully you now have an architecture with stable interfaces, even if individual subsystems need to be completely rewritten during the course of the project. [1] http://www.infoq.com/presentations/Architecture-Uncertainty http://www.infoq.com/presentations/Architecture-Uncertainty
    • kctess5 11y ago
      Disclaimer I haven't watched the presentation, though I do have first hand experience refactoring large systems that grew slowly over time. Based off of your edit's description, this technique feels like a patch that inevitably fall apart. It relies on the assumption that your team can correctly identify the centers of uncertainty, and that that uncertainty model will continue to apply. Thinking about such things is an excellent idea, but it is not sufficient - uncertainty is, after all, uncertain. I think in many cases the more important thing is to create an abstraction that allows you to perfectly represent your existing business logic in the most concise way possible. This should let you cut down on the number of edge cases outside the model, and generally simplify the system. Simplicity in specification is important, because it will allows newcomers to quickly understand the inner workings of your code, quickly correlating business logic with real code - if they can understand it, and can work within it, then they will not be tempted to hack around it (which is the root of code deterioration). I strongly believe that human friendliness and understandability should be key design goals in ANY new system, not an after thought. So long as no one breaks the abstraction, the 99%, day to day changes should be easy. When you finally do hit a case that requires a significant abstraction change, then your concise code will make it obvious that it's outside of your abstraction model, and can evaluate options at that point.
• davidgerard 11y ago
  Part of this is the fresh-eyes effect. Just having someone new look at things should result in good stuff happening in the first three months.