When I walked into the room, I noticed the haphazard arrangement... 3 short rows of 4 chairs each here... a circle of chairs over there... a couple of comfy couches and chairs surrounding a coffee table in that corner... 4 chairs around a small table... and some chairs in random locations, as if shaken up like a cupful of dice and somehow landing on their feet. I sat in the front of the 3 short rows. Other people were arriving, sitting down in various places in the room. We were waiting for the session to begin.
What we have to say, what you want us to hear.
That’s how our blog works. It’s interactive. Let’s learn together.
Technical debt is hard.
It’s hard admitting that technical debt even exists. Admitting it exists means that you’re admitting to maintaining code you’re not proud of. It may not be code you’ve written, but on the other hand it may very well be. Part of growing is learning, part of learning is to recognize that what you’ve done before could have been done better.
In conversations regarding technical debt (and technical improvement), I often hear that there is an understanding gap between technical people and business people. As an experiment, I thought it would be interesting to attempt to bridge that gap by illustrating what technical debt looks like, with an analogy.
In the Age of the Internet, what is the value of distributed teams?