A Field Study on Technical Debt
blog.sei.cmu.edu
A Field Study on Technical Debt
1–10 of 81 posts
Re: A Field Study on Technical Debt
#2Shameless plug: I didn't know about their SonarQube project until I'd built debt ceiling, but while ruby only at the moment, it is an open source attempt to provide some mechanics for defining and tracking some quantified approximation of technical debt. No claims it's perfect of course, but would love more real world feedback and/or feature requests! Also would like to extend it to handle JavaScript analysis as well, ideally through a plug-in architecture that could easily handle arbitrary other languages as well.
Re: A Field Study on Technical Debt
#3I 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 doing the same thing. Reflecting on it, for me it was a coping mechanism. I was overwhelmed by all the new things and didn't understand why this was setup that way, etc.
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.
Re: A Field Study on Technical Debt
#4I 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 doing the same thing. Reflecting on it, for me it was a coping mechanism. I was overwhelmed by all the new things and didn't understand why this was setup that way, etc. The reason I bring this up is I am surprised that architectural choice is overwhelmingly the to…
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.
Re: A Field Study on Technical Debt
#5I 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 doing the same thing. Reflecting on it, for me it was a coping mechanism. I was overwhelmed by all the new things and didn't understand why this was setup that way, etc. The reason I bring this up is I am surprised that architectural choice is overwhelmingly the to…
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. Thir…
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.
Re: A Field Study on Technical Debt
#6Earlier quoted context omitted.
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. Thir…
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.
Congratulations. You're the 1%, you don't need my services. :)
Re: A Field Study on Technical Debt
#7I 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 doing the same thing. Reflecting on it, for me it was a coping mechanism. I was overwhelmed by all the new things and didn't understand why this was setup that way, etc. The reason I bring this up is I am surprised that architectural choice is overwhelmingly the to…
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. Thir…
where are you working or interviewing?
I think, at least in sfbay, it's safe to assume git. And probably some CI tool. This is true across my personal sample of perhaps 15 companies that I know well enough.
Re: A Field Study on Technical Debt
#8Earlier quoted context omitted.
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. Thir…
where are you working or interviewing? I think, at least in sfbay, it's safe to assume git. And probably some CI tool. This is true across my personal sample of perhaps 15 companies that I know well enough.
You would be surprised. Even in the Bay Area.
The Bay Area is better than most places, but the moment you aren't dealing with a purely software shop, the probability they don't have this stuff goes through the roof.
The PCB design tool Altium only has provision for using Subversion (which is fine, thanks), but the number of people who actually USE it is miniscule.
Re: A Field Study on Technical Debt
#9I 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 doing the same thing. Reflecting on it, for me it was a coping mechanism. I was overwhelmed by all the new things and didn't understand why this was setup that way, etc. The reason I bring this up is I am surprised that architectural choice is overwhelmingly the to…
It just shows how completely subjective it is, and that "technical debt" is becoming an excuse for anything and everything.
Re: A Field Study on Technical Debt
#10I remember reading this http://higherorderlogic.com/2010/07/bad-code-isnt-technical-...
According to the author call options are a better metaphor for what we call technical debt but admittedly a more difficult one to understand: anyone who knows what a call option is raise hand.