Is it Typical for Large Software Companies to Not Document or Refactor Code? [closed]

Question

I have begun working at a large software company and was assigned to a project that is over a million and a half lines of code. It's part of a program suite that is sold to clients (not an in-house project) and the source code can be purchased if they desire (although given the extra fees associated with it, this seems rare). They've been doing software design for years and their current products are intended to be continued for the foreseeable future.

To my surprise, the million and a half lines of code are almost completely lacking in documentation. Moreover, there are some areas of code that are incredibly messy to follow or could use some refactoring to become much easier to understand (for instance, an improvement in the programming language came out 10 or so years ago that would make large portions of code much cleaner, not to mention less prone to bugs). There doesn't seem to be any efforts to rectify this and my offers to do so for the parts I'm working with have met with resistance, for which I've never really gotten a clear answer.

Are these practices common in a large business in the software industry? Or is my company unique in its lack of refactoring and documentation?

Addendum: Based on some of the comments, I'd like to clarify what I'm looking for. I understand that my company has technical debt and this is bad. I'm not looking to determine whether or not my company is worse off because of this, I am just wanting to know whether or not this lack of documentation and resistance to refactoring is a fact of life within the programming world that I'll have to deal with if I continue working in it.

Answer 1

There are a number of reasons why companies fail to invest in making their programs "better," from a technical debt perspective:

1. Reducing technical debt doesn't add any new features to the software. It is therefore perceived by management as having no monetary value (to a certain extent justifiably)

2. The nature of the software business awards first-to-market, not best.

I could go on, but all the other reasons are just variants of these two. They all basically add up to short-term thinking, focusing on immediate profits instead of long-term viability.

All companies with non-trivial, active software projects have some degree of technical debt. No company is completely debt-free.

Every software project I've ever worked on has accrued Technical Debt over time -- Jeff Atwood.

Regarding documentation specifically, the less there is, the better. Dollar for dollar, you get more return by making the software simpler to use and easier to maintain than you do writing more documentation for it.

There are some informal surveys about technical debt, and how companies manage it; all you have to do is look for them. Here's one:

Or this one:

It seems fairly apparent that your company is not the only one that has this problem. It may not even be in the minority.

Further Reading
Third International Workshop on Managing Technical Debt - Overview
Managing Technical Debt in Software-Reliant Systems

Answer 2

A perspective which I don't believe has been covered in other answers (yet) is the cost of change in three areas:

1. testing
2. re-familiarization
3. opportunity cost

A company with a large product will need to test all changes. These test procedures need to be tracked over multiple axes: different platforms, different workloads, different perspectives (performance, functional, usability, backward compatibility).

The people who work in the areas of code that you are changing will also need to then re-familiarize themselves with the code, and it becomes especially cumbersome with multiple versions being supported ("sorry, what version is that? Ahh, that's the new code and you need to speak to Bob for that"). In a similar vein, changing code just to make it pretty tends to make things like change-logs (diffs, patches, etc.) very complicated to read... and tracking issues back to a particular point in time when the bug was introduced can be very challenging if there's something in the code history that changes everything. Additionally, if a bug is long-standing (these things happen) it may be in multiple supported versions of your code, and now you have to fix the old, and the new code, in potentially very different ways.

Finally, often the decision has to be made where to spend time and money. This is more than just your time, but rather what you should rather be doing with your time (and the impact it has on down-stream resources). Would it be preferable to spend your dev-team's time on features that can produce more sales, gain new market share, and generate profit, or should the time/money be spent on things that end-users will not notice, cannot be put on marketing material ("hey, our existing code sucks, but we have made it better") and is pure cost (no profit).

Bottom line, money. Always (well, almost always).

Answer 3

Yes. Based on the 50 or so companies I have personally encountered, as an employee or consultant, and the 200 or so more companies I know of via colleagues.

The kind of product (1.5 million lines) you describe took years to build, and many of the original devs have moved on (or become managers).

The senior management and major continuing clients want only small incremental change: they want stability. What we technical people think are improvements are in their eyes risks. Even if we can show the new version still behaves the same as the old one, they see a risk because the old system has exactly the characteristic you describe: it's undocumented. To them, there could be undocumented behavior that clients rely upon.

From their perspective: it ain't broke, so don't fix it. You are also seeing that there is a corporate culture to that effect. The people who are resisting your "improvements" probably did the same as you when they started.

Do not expect to "win". This is a cultural issue, and cannot be changed except by change at the CEO level.