How are people able to maintain their codebases?

Question

I'd understand how if the codebase were good but more often it's more like a maelstrom.

In code I'm asking about the variable names are foobar, stuff is getting calculated even if never needed, lots of hacks and patches are applied, abstractions fail, deployment scripts fail... The code is an incomprehensible and almost unusable soup.

To be able to maintain my codebase, I must name the variables well, document my code, keep sure nothing gets repeated, that abstractions are working so that hacks aren't needed.. and comment sparingly because comments often interrupt me reading the code.

So! I'm curious. How in the hell are you doing it without this all I need to do for it?

Answer 1

Documentation, source control, unit-tests, and being a good programmer.

Answer 2

Constant refactoring; when you open a code-file and you see something strange, you can invest a few minutes in order to improve the design of the existing code.

Having a suite of unit-tests may help you with it, as it gives you confidence on whether the code you're changing still works or breaks because of your change.

It is a bit like the story of having a broken window in a house. When you see a broken window, you should fix it. If you do not fix it, things will start to detoriate from there, and it will result in an unmaintenable mess.

Most of my projects are also put onder ContinuousIntegration; next to building and running unittests, a statical code analysis (fxcop) is performed as well. Now and then, I have a look at the results, and try to fix some violations that are being reported.

Answer 3

A comprehensive suite of unit tests that allows for changes and refactoring without worrying about breaking existing code.

I recommend picking up a copy of Michael Feather's "Working Effectively with Legacy Code".

Answer 4

Peer reviews quickly establish a code quality norm that is hard to quantify on a piece of paper. Unit tests allow you to change code with little fear. Discipline, lots of it.

Answer 5

Fridgemagnet say : "Dull programmers have immaculate codebases"

Answer 6

You just need practice, good tools and ability and willingness to break bad habits and learn.

Answer 7

This is just the case when you write the code and other people read it
1. Left the bad habits
2. Use meaningful procedure, function, variable name
3. Use documentation about how it (procedure/function/calculation/etc) works and what resulted from what, don't make any unnecessary comment
4. Try to give style to your coding so people can know it (such as using GNU style code)
or
Use code beautifier for that
5. Think to work as team (even if you were alone) and not only you that will read your code (even if it was)
6. Refactor code should be good as well
7. Consult with your teammates about the code you were write, can they read it?
8. Learn from OpenSource community, how they work and share codes & patches
9. If you can, use SVN or CVS for maintaining your code

and remember KISS principle (Keep It Simple, Stupid)

and ofcourse Simple, Lean, Mean & Beautiful

if it reversed (other people write, you read) i didn't know what to said :D (maybe give that people above advices LOL)

Answer 8

Generally what you describe is the natural tendency of any code base to increase entropy. It happens in every project by the virtue of it being developed and maintained. To combat this steady increase I would suggest the following:

1. Someone on the team with sufficient authority has to care. This is the most important part. If nobody cares, it won't get done. This point seems obvious, but it is not.

2. Set standards and best practices. Most languages have a book written by someone about best practices. For example in PERL there is a very good Perl Best Practices book by Damain Conway. Unless you do this, every person on the team has his own way to write code, name variables, comment and so forth.

3. Code Reviews. You will need a checklist for code reviews. It is not enough that your change works, it has to conform to the list of best practices as well. We set up a two tier code reviews, first tier are peer code reviews and second tier is a release manager who cares about the code quality.

4. Design Reviews. When bug or enhancement is filled in bug tracking system, it is important for it to get reviewed by a change control board, that decides on scheduling of the work and also about who needs to review the design of the work. This is where you maintain the code abstractions and make sure the change will conform to design documents and goals for the project. The software architect of the team or a lead designer should be part of the CCB.

5. Checkin code quality triggers. Some best practices can be directly enforced by code. Write small scripts that check your code for things like formating, use of tabs/spaces and such. This will help you think about code quality in a different way.

Some reading for a reference.

Answer 9

How in the hell are you doing it without this all I need to do for it?

How do people get away with it, in other words? A good strategy for incompetent people in our industry is this:

1. Develop the ability to sound impressive especially to the non-technical and semi-technical people. Be able to sound plausible enough to the technical people, enough to keep them off-balance.

2. Make a complete mess of the code you touch.

3. Now this is the crucial part: Leave and find a better job elsewhere just before you are found out. The best timing will depend on the particular circumstances.

Answer 10

It happens because it has to. You can only get away with that when you are a very small (less than 10-20 person or so on a single project) development team. If your project grows and your team grows, either your practices will scale up or you will fail.

The change you are asking about is essentially the transition from hacking to programming and finally Software Engineering.

With Software Engineering you recognize that not everyone in the team is perfect. You review code, you ensure that others test, you cross-check each other.

You start to see the need for an architect that can digest the customers desires and translate them into a design document. This can easily eat a month of time before anyone else is even added to the project (but over the course of development time can save months or even years!). He makes sure that everything makes sense and will fit together reasonably well.

You have design documents, generally UML based so that different parts of the team can understand integration points . You recognize that anything that has been done, you may need to re-do without the people who did it, so you document it.

Your quality process gets much more strict and they start enforcing rules like you only check in changes that address specific bugs during testing.

Testing, refactoring, etc. are obviously key and are re-enforced by peer and team review.

I'm not saying this type of stuff is always necessary, obviously it's not, but you asked why your code base is looking crufty, and this is often the solution to that problem.

Usually this happens after a GIANT project that completely fails because the codebase sucks so bad. Then they fire anyone who can't dodge the blame, hire some managers who hopefully have some experience with larger projects and (if they don't run out of money) restart from ground zero.

At least that's my experience. YMMV

Answer 11

I'd like to introduce you to a term I heard a few years ago - Technical Debt. Here's a (1) Wikipedia entry and another from Martin Fowler's (2) web site.

Essentially, I don't think people start out aiming to build crummy software. What typically happens is that timeframes are compressed, requirements are modified or replaced mid-development and any number of other commercial realities bite at the heart of quality development and design.

From Fowler:

"doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice."

From Wikipedia:

"Activities that might be postponed include documentation, writing tests, attending to TODO comments and tackling compiler and static code analysis warnings. Other instances of technical debt include knowledge that isn't shared around the organization and code that is too confusing to be modified easily."

What I've seen (and directed several development teams to do) is to refactor and clean the code base early into development iterations, usually at the start before new work is developed.

Peer reviews, unit testing and professional software testers all help to repay some of that technical debt, as well as good forecasting (and good code reuse).

If you have the budget, automated testing can be a sound investment as long as you are willing to pay the upkeep (time, effort).

There are plenty of quality tools around today such as fxCop (and others like it) however you have to carefully choose which approaches you're going to entertain.

Effort in maintaining quality in design and in the code base has to be accounted for, so think carefully about the most effective and useful way for your development team/product/company/customers etc.

[ (1) http://en.wikipedia.org/wiki/Technical_debt ]
[ (2) http://martinfowler.com/bliki/TechnicalDebt.html ]

Answer 12

Coding is much like handwriting. Everyone has their own distinct style. One of the biggest challenges I've faced while maintaining legacy code, is trying to figure out what is going on. Usually it comes down to lack of consistency in the codebase.

Answer 13

Discipline