
Ask HN: Does any body work on a huge (and old) code base that is not a mess? - scotch_bright
Longer Version Of My Question:
Is there anybody who works for a company where there is a huge code base that has been around for a few years and is NOT a mess to deal with? If your code base is NOT a mess, what are you doing to keep it that way (functional programming, OO, training)?<p>Still Longer Version:
I am trying to understand the state of the industry.<p>Systems will always get more complex. There is no doubt about that. But I am interested in knowing if there is something that teams are doing to ensure that years after working on a code base, new changes &quot;feel easy&quot;.<p>&quot;Feel Easy&quot; would be explained as: A new change comes along and it is clear and apparent that they just have to add a function somewhere and they are good to go. (Things like TDD help with giving confidence. But, TDD does not catch it all. So, even with TDD we still have to cross our fingers.)<p>&quot;Not Feeling Easy&quot; is when a new change comes along and it feels like: &quot;Okay, to make that work, I am going to have to go check X and Y. Then I will cautiously make the change and hope that nothing else goes wrong.&quot;<p>Design Principles In OO are supposed to give this to us. But what is the reality in the wild? Does everybody feel like they have delivered on this promise? Or do changes still feel difficult to deal with?<p>Is this an inherent problem to code&#x2F;programmers&#x2F;human nature. Or maybe it is not a problem. Maybe there are teams and companies where the above does not happen. (I have not seen any. I have been in the field for quite a bit. But is it my exposure that is lacking? Or is this a problem everywhere?)
======
PaulHoule
The unappreciated key to rapid software development is having a realistic
plan:

[https://www.amazon.com/Rapid-Development-Taming-Software-
Sch...](https://www.amazon.com/Rapid-Development-Taming-Software-
Schedules/dp/1556159005)

"Point the boat in the right direction and row" is the dominant paradigm in
the industry.

The concept of "technical debt" is I think harmful because it is a two word
phrase that stops thought. In the real world if you want to take on commercial
debt, the bank and/or bondholders and originators are going to want to see a
detailed financial analysis that will indicate they will get their money back.

Probably 80% of effort on software is maintenance, but it is rare for any
project to start out thinking about the cost of maintenance.

~~~
Jtsummers
As a maintenance programmer, you're 100% correct. Our systems are not designed
to be maintained and so our ability to work is severely hampered.

Within the area of maintenance programming, if you inherit a program with a
poor testing infrastructure (or even worse, have to produce it yourself) you
will make the system worse over time or move at a snail's pace.

Automated testing and unit tests need to be present to make effective changes
during maintenance to systems. Otherwise too many of our changes are shots in
the dark. They add the feature we wanted (we can test that much), but may have
broken a dozen other things that we won't see until much later in the
schedule.

A lack of automated testing and good unit tests also motivates managers to
adopt more waterfall-styled schedules. Pushing integration of the various
change requests to the last possible moment, with a comprehensive test suite
run after that. This creates huge schedule risk, but from their perspective is
necessary. Why? Because they don't want to spend the time/money running that
huge, comprehensive, largely manual test suite more than once in a year. They
don't accept that a partial test suite (a representative sample, if you will)
could be executed with greater frequency and give similar results, with the
full suite run once for certification testing at the end.

~~~
PaulHoule
You're definitely right that unit tests are a part of the solution.

[https://www.amazon.com/Working-Effectively-Legacy-Michael-
Fe...](https://www.amazon.com/Working-Effectively-Legacy-Michael-
Feathers/dp/0131177052)

can be read in a few different registers (making a case for what unit tests
should be in a greenfield system, why and how to backfit unit tests into a
legacy system) but it makes that case pretty strongly. It can seem
overwhelming to get unit tests into a legacy system but the reward is large.

I remember working on a system that was absolutely awful but was salvageable
because it had unit tests!

Also generally getting control of the build procedure is key to the scheduling
issue -- I have seen many new project where a team of people work on something
and think all of the parts are good to go, but you find there is another six
months of integration work, installer engineering, and other things you need
to do ship a product. Automation, documentation, simplification are all bits
of the puzzle, but if you want agility, you need to know how to go from source
code to a product, and not every team does.

~~~
Jtsummers
That book is something I wish I'd read when I started my career. This is a
holiday week so all the management types were out, but I had planned to have
management buy a copy for the office library next week. I still need to finish
it, but most of what I have read, I've been able to apply to projects in the
past. I should probably actually reread it because it's been a while.

------
carlsborg
I have seen large c++ code bases extremely clean and well structured even at
scale, a real pleasure to work with. These projects were mostly birthed in the
early/mid 2000's when architecture and design patterns were religion.
Somewhere along the way "design" became a dirty word.

~~~
scotch_bright
That is a great point. Design Pattern and CS fundamentals are old and have not
changed for 20-30 years. These are problems that have been solved ages ago. I
can completely imagine what you are saying about the old C++ code bases to be
true.

What do you think happened to us?

Uncle Bob says the web happened. Maybe back in the day when you had to make a
program that ran on the console things were simpler. Now for a standard web
application we need to worry about JS and CSS and HTTP and HTML and
WebSockets. (And then the app needs to support different clients like Web,
Mobile Web, Native etc.)

I am talking about this since thats the kind of software I build and I know
that it is always a mess.

But there are still C++ programs written today that are not for the web. Are
they also a mess? If they are then the web is not the problem.

~~~
carlsborg
I think there are different classes of applications, \- some that don't really
need any time spent on design at all, and some that absolutely do - and for a
while the former class of applications became predominant (possibly because of
the rise of quality middleware and frameworks that did the heavy lifting ),
and the methodologies became mainstream, and adopted universally.

Hard to generalise beyond that.

------
scotch_bright
In case you see this and feel like the code base you work on is also a mess,
then I think it would be a good idea to post something like: "I work at XYZ,
and the code base is a mess." (Maybe leave out the company name if not
comfortable. Just a size of the company will help.)

I am urging you to do so, since atleast then we can move ahead and accept that
this is the state of affairs. If we don't do that it will not be clear weather
this is a problem or just an un-interesting discussion.

~~~
k_
I work for a small company (< 10 developers until last month, and suddenly
growing) working on a project since around 2013.

I arrived a month and a half ago, and am leaving tomorrow.

I haven't been able to make much sense of the current state of the
application, which constantly needs new features (to be delivered yesterday).
For each task you need to dig into countless files with a filename of ~50
characters, often with several classes, with a size ranging from 300 to 7000
(for a few files) lines. You are asked to copy paste existing solutions and
modify some things to make it work for your feature.

The code is a total undocumented mess (the copy-pasted javadoc all over the
place doesn't help at all, since it's only rewording the function/variable
name.. when it's not utterly outdated). Dead code everywhere, hundred of
warnings (they use the closure library) due to bad code annotations (which do
nothing at all), unreachable code, mistakes (comparing to NaN), or code doing
nothing (often due to a type annotation mistake).

I'll try to find another company, maybe with a recent project or an old one
which they are rewriting _right now_. My current company's pitch was that the
goal was to migrate the current application (in closure library) in something
like react, but the reality was something else entirely and I doubt they will
begin the transition any time soon.

My previous companies were having similar issues (I left my previous company
because the main project was falling appart and the CTO was refusing any
attempt to rewrite the product, even if it's beginning to cost less to rewrite
it entirely than to meet the clients needs by adapting the current version..),
and I really hope I'll find myself in a situation where I am not silently
swearing a dozen time a day at poorly written code.

~~~
scotch_bright
Wow. Thanks for that. Sadly enough it does seem like things like this are very
common. This is super important because “software is eating the world”. A
car/aeroplane/subway system etc all have code powering them. So our lives
depend on software that other folks (just like us) write. Yet nobody here has
said that the code they work with in their companies is not a mess.

And the norm seems to be that code always turns into a monster that nobody can
control. At best we seem to test pre and post release and hot fix things till
they work satbly.

------
segmondy
There are such code bases, look to the OSS projects to learn.

Linux, FreeBSD, MySQL, Postgres, Apache, a lot of your favorite projects have
been around for quite a long time. We don't consider them legacy, but they are
if you use that to refer to software that has been around for a long time.

~~~
scotch_bright
Great so OSS projects also have a very large number of people coming together
and collaborating. How do they stay clean? Why is there a mess in the code
that gets made within companies? What do you think the difference is?

~~~
chatmasta
You’re making a huge generalization (all OSS is clean code, no internal
projects are clean code).

Ignoring that, let’s hypothesize a reason why you might find higher quality
code in OSS. Perhaps it’s because company code has deadlines and pressures
unrelated to the code quality, whereas OSS is _solely_ about code quality. For
company projects, the customers are the users. For OSS projects, developers
are the users. Requirements for companies revolve around customers, who never
see the code (other than companies building products for developers).
Requirements for OSS revolve around developers who will be using the code.
Given this, and the fact that OSS is a much lower pressure environment, it’s
not surprising you might see cleaner code in OSS software than internal
company software.

tl;dr OSS focuses on code, companies focus on customers.

~~~
scotch_bright
Yes. I am simply accepting the premise given and trying to explore from there.
I am aware of the generalisation.

But, your answer does help us move ahead. It basically says that there is a
way to produce a high quality code base. It is not impossible. The right set
of circumstances seem to be: 1\. No deadlines 2\. Focus on code quality

The "no deadlines" part I take to mean that within OSS projects there is time
to refactor to perfection. There is time to design, comment, document and
indent to perfection.

So, your point is it is possible. But it seems like within the context of a
company, it almost never happens. (Nobody has still posted here to saying that
their code base is not a mess. A lot of people have now seen this.)

When one thinks about that, it is just weird right? The people who get paid to
make software do things that make their work un-productive. And the opposite
is true for good OSS.

~~~
chatmasta
Well, it seems like there exists a tradeoff between code quality and profits.
Profits provide incentive, and therefore pressure, which manifests itself in
deadlines. If we think of deadlines as time windows, then the tradeoff is
really between code quality and _time_. Everyone knows this; rushing through
projects will reduce their quality.

Given all this, it should not be surprising that corporate code is “lower
quality” than OSS. The authors of each are optimizing for different metrics.

It’s only weird if you think companies are irrational for prioritizing
deadlines over code quality.

------
ttoinou
I don't understand your point. You would like to know which techniques that
minimize work involved in maintaining a codebase / adding features ?

It's true that it's a topic not very well researched but you also have to take
into account others factors (economic, management, incentives, planning etc.).
For example, following Conway's law (
[https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)
) the software codebase complexity and the way the team is organized are
connected. There might be no silver bullet at all (e.g. it's a hard problem
involving human coordination)

~~~
scotch_bright
Okay. I will study more about Conway's law. Thanks for that.

What I want to get at is: Is this the "normal" state of affairs? Do all
projects devolve eventually? There seems to be a lot of work that has been
done on Deign Patterns and best practices to write code etc etc. And this work
was done 20-30 years ago. So, what explains the mess we see everywhere? Thats
what I want to find out.

