What is code quality ?

So starting the new jobs has given me the opportunity to take a fresh look at software and how it should be approached.

One of the questions that I have been pondering on alot is “What is code quality ?”  Is it code that’s well documented ? Is it code that follows some sort of coding convention, code that is uniform throughout ? Well named variables ? Test cases ?

Obviously we all have our own perceptions, but in order to write good software I think its important to look at code from multiple perspectives, in order to do this I need your guys feedback!

Please tell me what you think makes good code ?

But haven’t we always been working this way?

When I was a kid I had a Commodore 64 with a cassette player, awesome little machine with cool games! I decided I had to write my own game, this is where it all started some 25 odd years ago. I decided I would write a “maze-like” game where an “avatar” would navigate through a maze picking various “gems” and scoring points, that was my goal anyway.

I started by skilling myself up in the basics of, well, BASIC (from books and magazines I had), once I knew enough to do the basics I put code to screen and started churning out lines of code, every now and then I would take a checkpoint and verify that everything still matched my goal…

draw the sprite, done, run and check the results, looks cool, figure out how to move it, done, write to code to make it move, done, run the code and see if it moves as desired, bugs!, change the code to work properly, sweet!

Excellent… time for a break, have something to eat and think about if I could do anything better, nah, the results looked good, was working as well as I had hoped.

I repeated this process until I had a working “game” knocked out. Every time I had a problem I couldn’t overcome I would simply change what I wanted, as long as it matched what I ultimately wanted, a (cool?) game with an avatar moving around a maze and scoring points by picking up stuff…

Sound familiar?


Having recently been on a round of interviews looking for that ideal job I thought I’d write down some of my thoughts on the whole process of interviewing the interviewer, or, knowing what you’re getting yourself into!

As a start let me first say that the word interview, in my opinion, is not the correct term to use as all:

interview ( ) n. A formal meeting in person, especially one arranged for the assessment of the qualifications of an applicant.

…implies a one way assessment of interviewer(s) over interviewee. This was (and in most cases still is) the traditional way of looking at this process, essentially you (as an interviewee) get grilled by one to many people to determine if you’re an acceptable candidate. You generally get time to fire off one or two irrelevant questions about pay and leave and that’s about it. I think this is ridiculous, that’s like signing a contract without reading or at least understanding it!

I prefer to use the term negotiation:

negotiation ( ) n. mutual discussion and arrangement of the terms of a transaction or agreement…

…implies a two way assessment, they interview you, and you interview them. Yes, interview, as described above, just like they interviewer is there to determine if you’re a good candidate, you should be there to determine if the company is a good candidate for you, the “sale” should come from both sides.

Entering an interview prepared for me is key, and I don’t mean reading up on the company and understanding their business etc etc… that’s just common decency (or common sense?). What I mean is having a thorough list of what you think are important criteria for you to accept the position they’re offering, and don’t be afraid to ask the important questions!

As an example during a recent interview I asked this question of the manager who would ultimately lead me:

“You seem like a manager that has his head in the right place, what are the chances you will resign and/or leave within the first few months I’m employed?”

A very relevant question, the company was strongly corporate (heirarchical, dictatorial, classic waterfall) but this manager worked in an agile, collaborative way. Everything would change if he were to leave.

During my interview for a ScrumMaster position I asked this question of the CEO:

“So what do you think of scrum?”

For me extremely relevant, resistence to agile methodologies is a surefire way to fail, change must be driven from, and embraced at, the highest level.

A while ago I read an interesting excerpt from an article by Bruce Eckel, it was titled: Interview Questions You Wish You Had Asked:

  • If I want to buy something like a book or a tool, how does the process work (how hard is it?).
  • What’s the cost limit before the approval must go up the management chain?
  • What’s the noise level like during the day?
  • How many meetings am I expected to attend, and how long do they usually last?
  • Is there a dress code?
  • Can I work from home sometimes?
  • Does it matter when I work, as long as I come to meetings?
  • How many projects have succeeded/failed in the last five years? To what do you attribute the failures?

Again, all relevant questions to ask!

What I’m trying to get at here is don’t short-sell yourself, have enough respect in yourself to know that you’re the right person for the job, and take the attitude that you have all the opportunities in the world available, it is up to the interviewer to prove to you that their opportunity is the best!