I work with codebase that has revisions going back over five years. Like dog years, the age of code adds up quickly. A five year old source file is like fifteen in code years. In that amount of time, boat loads of engineers have come and gone, checked in fixes and bugs alike, have left comments, and removed methods. Code has been written and rewritten and refactored and removed in that time span. Third party vendors emerge, merge, and disappear.

The codebase is large, with thousands of class source files and millions of line of code with hundreds of third party resources. No one person alone knows the system inside out, it’s behavior is a mystery to some. To grasp it in your debugger or your mind you need the collective knowledge of the whole team. In such an environment, tests are that much more important. Test become a part of the collective knowledge, an opinionated specification, and essentially another team member, of sorts.

Debugging such legacy source code becomes like code archeology, but instead of finding ceremonial tombs encrusted with jewels you find unceremonious hacks littered with bugs.

After reading thousands of source files, like the matrix, you begin to recognize patterns, fads, and trends, like XML configuration files, to code generation, to dependency injection, to annotations, to configuration over configuration, to new languages, etc.

Along the way, your realize that if code is art, then having Picasso on your software development team would not necessary help keep defect count low.

Technorati Tags: code, softdev, software, development, archeology, programming, rant, art, hack

has a good tech talk on How to Design a Good API and Why it Matters that he does from time to time in the conference circuit. He outline that talk with one liners, he calls them bumper sticker API design. Below are some of my favorite bumper sticker API design advice, if I had a wide enough car.

• All programmers are API designers.
• APIs can be among your greatest assets or liabilities.
• Public APIs, like diamonds, are forever.
• APIs should be easy to use and hard to misuse.
• APIs should be self-documenting.
• Example code should be exemplary.
• You can’t please everyone so aim to displease everyone equally.
• Expect API-design mistakes due to failures of imagination.
• API design is not a solitary activity.
• When in doubt, leave it out.
• Keep APIs free of implementations details.
• Minimize mutability.
• Minimize accessibility.
• Don’t make the client do anything the library could do.
• Obey the principle of least astonishment.
• Use consistent parameter ordering across methods.

Technorati Tags: effective java, software, design, api, bumper sticker, bloch

Vinh Phat was one of my professors in school. On the first day of lecture, he goes of into his philosophy of learning, a philosophy of life long learning, where the answers he gives are not the answers, but clues, for he says he is more a guide than a teacher. He went on to say…

You memorize the night before and forget the night after.

My job is to understand you, your job is to understand me.

Ask questions. But remember that, if you ask to much, you annoy yourself. If you don’t find the answer, you can drive yourself crazy. Ask yourself, why do I need to ask that question? And learn to be sensitive to the question and the answer. So that is how you learn, memorizing is the stupidest thing on earth.

Technorati Tags: learning, computer, science, programming, memorizing

Here is a pile of quotes and anti-anecdotes relating to software development and programming in general. The quotes where compiled by digging through the mining the rants from Juixe TechKnow. The collection of programming quotes is available as a PDF document and can be found on scribd.

Your code does not start at the compiler nor does it stop at the JVM.

One lesson that most developers don’t learn is to debug outside the debugger. As an engineer there are times when you need to troubleshot, problem solve, and debug not just your software from the comforts of your favorite IDE but the whole software stack, network, hardware, user’s environment, and even the user himself.

You can unit test and statically analysis software, but you can’t probe your users.

Every problem, issue, and bug experienced by the end user directly and indirectly with your software eventually needs to be implicitly and explicitly dealt with by your software development team.

I wish development teams spend more time streamlining their process rather than prematurely optimizing their code.

It is OK to have software with bugs, bugs can be fixed. It is not OK to have software with excuses!

Learn, plan, design, code, integrate, build, release, rinse, and repeat.

Management has a way of over emphasizing the blatantly obvious.

I’m a lazy loading type of programmer.

I’ve discovered that Windows security is an oxymoron!

I know that techies, myself included, are always bragging about how their code is poetry but I have never meet a poet laureate in a development team.

Remixing and mashing up Google Maps and Flickr is like the ‘Hello, World’ first program of Web 2.0 mashups.

Open Source code equals community.

As a rule of thumb, I never cache, pool, or use as singleton mutable objects.

Bugs by nature are out of the box, as a developer, you need to expand the box.

WWGD: What would Google do?

At some companies, the term Spec stands for Speculation.

I went to school to learn how to program software applications, which inevitably have bug defects. There was no course at my university on testing, debugging, profiling, or optimization. These things you have to learn on your own, usually in a tight deadline.

To most Java developers, Ruby/Rails is like a mistress. Ruby/Rails is young, new, and exciting; but eventually we go back to old faithful, dependable, and employable Java with some new tricks and idioms and we are the better programmer for it.

You might as well hire your your customers and pay them 50K/year because they are your new QA.

There is a saying, those who can, do; those who can’t, teach. It can be said that in software engineering, those who can, code, those who can’t, manage.

The greatest thing about Ruby on Rails is neither Ruby nor Rails, the best aspect of Rails is that it questioned the ‘best practices’ (and worst nightmares) of the current state of web development with its philosophy of Convention over Configuration and Don’t Repeat Yourself principle.

Read more »

Devshop has created a satirical video of developers in tough times. The video is of software developers standing on street intersections or sitting on the floor outside coffee shops holding up small cardboard signs. Here is some of the text from the cardboard signs.

We’re 4 months into a 5 month schedule and I just received the final requirements yesterday. (and they’ve changed again!).

I spend half my days in meetings about how to get more work done. (instead of working).

My boss read in a magazine that developers using “____” programming language are twice as productive. So he bought us a copy and cut our schedule in half.

This is funny because it is true.

Technorati Tags: software, development, devshop

The first 90 percent of the code accounts for the first 90 percent of the development time…The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Tom Cargill

Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.
Larry Wall

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
Bill Gates

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Brian W. Kernighan

Once a new technology starts rolling, if you’re not part of the steamroller, you’re part of the road.
Stewart Brand

In theory, there is no difference between theory and practice. But, in practice, there is.
Jan L. A. van de Snepscheut

The hardest part of design … is keeping features out.
Donald Norman

Before software can be reusable it first has to be usable.
Ralph Johnson

If debugging is the process of removing bugs, then programming must be the process of putting them in.
Edsger Dijkstra

Software and cathedrals are much the same - first we build them, then we pray.
Anonymous Preacher

The goal of Computer Science is to build something that will last at least until we’ve finished building it.
Anonymous Consultant

The software isn’t finished until the last user is dead.
Anonymous Support Group Member

Better train people and risk they leave - than do nothing and risk they stay.
Anonymous Technical Trainer

Programming is 10% science, 20% ingenuity, and 70% getting the ingenuity to work with the science.
Anonymous Scientist

All programmers are playwrights and all computers are lousy actors.
Anonymous Hack Actor

Bad code isn’t bad, its just misunderstood.
Anonymous Code Behaviorist

It is easier to measure something than to understand what you have measured.
Anonymous Analyst

The sooner you get behind in your work, the more time you have to catch up.
Anonymous Scheduler

When a programming language is created that allows programmers to program in simple English, it will be discovered that programmers cannot speak English.
Anonymous Linguist

Benchmarks don’t lie, but liars do benchmarks.
Anonymous Tester

Why do we never have time to do it right, but always have time to do it over?
Anonymous Code Monkey

Technorati Tags: quotes, programming, software development, softdev, anonymous, code, monkey