Kirill Osenkov
Witnessing debt in a large codebase. Small things, like tons of repeated code in tests. Instead of extracting a helper or finding existing code that does what you need, people just copy-paste or slap something together and move on.
I think it's natural that people want to get their task done and move on, and don't care about keeping the "cesspool" clean.
Sergey Shandar
@KirillOsenkov People who don't have capital, implement the dreams of people who do. Hmm, let's call it capitalism. I can say it's a little better than feudalism and communism (as we know it) but still far away from real freedom.
Kirill Osenkov
Another person I know was working on making Windows builds faster. They found a process that took 45 minutes, and could be made significantly faster relatively easily. They approached the author of the tool, and the author replied “yes, we know. we just don’t care”. Nobody in management cared either. The person who wanted to fix it left the company.
Kirill Osenkov
Got some good wisdom in the replies in this thread, check them out!
Kirill Osenkov
I’ll give you some examples. Someone went out of their way and converted a few hundred projects to SDK style. It was hard work, took a long time, but massively improved life for several hundred people as a result.
They got a bad review because of this and quit the company in frustration. This is how the team lost someone talented and motivated who tried to improve things.
Kirill Osenkov
I don't know where I'm going with this, I'm just a bit sad. I don't have any ideas on what would make things better and what is even "better". Software is hard.
Kirill Osenkov
More thoughts: tech debt is low visibility, cleaning it up is discouraged, unrewarded, but also difficult and sometimes risky. Also it does take away from adding measurable value. People are not incentivized to clean it up.
Also it's never built into schedules, estimates, never prioritized or funded properly.
Explaining the need to pay some of it off is often futile, as management is simply unable to understand it if they're not engineers. It's bad for morale and productivity.
Kirill Osenkov
Either some employees will fight the entropy in their spare time and at their own expense, or it will grow uncontrolled. If you see a product that was once great, but is now a bloated buggy piece of garbage, uncontrolled entropy is likely one of the reasons why.
The part that makes me the most sad is the people who choose to fight it on their own are often talented and could have had more impact doing something entirely different. But they're doing it because no one else will.
Kirill Osenkov
This is a sensitive and complicated matter and I don't know what the right thing is and what can an individual do if anything.
All I know is entropy increases. It is an inevitable process. In most cases it's an inconvenient truth that management/leadership prefers to ignore, or simply not know or care about. They're all about "business value", "delivering features", "impact", "visibility", etc.
Kirill Osenkov
Some of us are cursed by the innate desire to keep things clean, maintainable and well-organized. Instead of going home to our families and having a life, we choose to stay and refactor, and clean up after other people. The problem is when the debt compounds enough it starts to slow down the whole product and maybe even doom it.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.