Observations from an Old Maintenance Programmer

G. Wade Johnson

Who Am I?

Professional programmer for over 25 years. Notable features of my career.

• Programmed professionally in 8 different languages.
• Worked as a programmer in 9 different industries.
• Wrote code to run on 5 different operating systems.
• Worked in companies ranging in size from 4 to 200k people.

Our Business is Different

Used to justify not adopting a best practice: version control, unit tests, coding standards, agile, training, etc.

• It might work for others, but the problems we work on are harder.
• We have really good people, we don't need that.
• That's fine for academics, but we have a business to run.
• We don't have time to change.

Legacy Code - The Belief

• The legacy system is a disaster we should rewrite/replace it.
• The hot {silver bullet} will fix it all.
• The previous developers didn't know what they were doing.
• We could do a much better job.

Legacy Code - The Reality

• The legacy system pays our paychecks.
• Much of the cruft on a legacy system is scar tissue from lessons learned.
• There's no silver bullet.
  • (Read the Mythical Man-Month until you get this)
• The previous developers did the best job possible with the knowledge and resources they had at the time.
• Our knowledge is still imperfect and we probably won't do a 10x better job.

Legacy Code - Bad Design?

• When you start building a project, you know the least about it you ever will.
• Any decisions you make early on are based on flawed information.
• Even good decisions can be overwhelmed by changes in environment.
• In hindsight, many reasonable decisions look like bad ones.

Realistic Design

• In the future, some of your great decisions will look naive.
• There is no one, true way to develop software.
• Every design is based on a series of sub-optimal trade-offs.
• A good design has attributes you want, with downsides you can live with.
• A good design is a study in careful trade-offs.

What's Important?

What is the most important thing we get from writing code?

• Revenue?
• Customers?
• Software?
• Knowledge

(Programmer) Religion

There is no one, true way.

• Not language
• Not paradigm
• Not brace/indenting style
• Not editor
• Different things work for different people

Language Doesn't Really Matter

That's a lie. But not as big a lie as you think.

• A bad programmer can write Fortran in any languuage.
• A good programmer can write good code in almost any language.
• All general purpose programming languages are Turing-Complete.
• Languages differ in what they make easy.
• Languages differ in the community/philosophy around them.
• Other languages look ugly because you don't understand them, yet.

Know Your Tools

• Language
• Compiler/Interpreter
• Libraries
• Editor/IDE
• Version Control
• Tooling: CI, static analyzers, etc.

Process

• Processes suck.
• Processes are vital to be productive.
• Good process won't fix a bad developer.
• Bad process can chase off a good developer.
• The formal process should not prevent the informal process from working.

Pitfalls

• The senior people have experience. Pay attention to them.
• The junior people ask stupid questions. Pay attention to them.
• Never ask Why would anyone do that? about customer input.
• Software always has bugs.
• Despite best intentions, we will make mistakes.
• Risk analysis is important.

Always Be Learning

• If you aren't learning, you are falling behind.
• The best programmers I know have spent a lot of free time working on code.
  • Most of that never saw the light of day.
• Study new languages, paradigms, programming problems, puzzles.
• Learn things outside your field.
• Read
• Don't experiment (much) in production code.
• Practice fundamentals.
• Teach, give talks.

Most Important Engineering Principle

Good Enough

Sometimes invoked recently as YAGNI

Rewriting Code

• A complete from the ground re-write is a horrible idea.
• Sometimes (less often than you think), it's still the right thing to do.
• Small improvements add up.
• When you remove cruft, make sure you know why it is there.
• Don't break a working system for a theoretical improvement.
• Sometimes you have to make it worse to get better.
• If a piece of code is ugly, unreadable, no one know how it works, but it doesn't fail, leave it alone.

Constants

• The technology and industry changes.
  • Sometimes old truisms no longer apply.
• Fundamentals always matter.
• It's hard to bolt on security.
• It's impossible to bolt on quality.
• Validate all input.

Industries I've Worked In

• Medical Research
• IVR for mortgage companies
• Personal investing information
• Energy management systems
• Software configuration management system
• Investment banking
• Geoscience
• Web hosting
• Electronic prior authorizations

Languages I've Used Professionally

• Fortran
• C
• Forth
• JavaScript (pre-jQuery)
• Java
• C++
• Perl
• Ruby

Operating Systems

• MS DOS
• Windows
• Windows NT
• Solaris
• Linux

Common Themes

• Everyone is too busy.
• Finding good developers is hard.
• The next new thing will disrupt everything.
• We're the ones solving really hard problems.

Education

• I've seen no strong correlation between programming ability and formal CS education.
• All of the best programmers I've seen are always learning.
• Good mix: seasoned developers, solid intermediate developers, junior developers.