Meme-ishness

I have apparently been memed.

How old were you when you started programming?
18 - first year of university.

How did you get started in programming?
I was studying business analysis and decided I should do Programming 101 so that "when I had to work with programmers I would have some idea what they were talking about."
Turned out that programming is a lot more fun that business analysis, so I ended up changing majors.

What was your first language?
Object Pascal, using Delphi.

What was the first real program you wrote?
I can clearly remember our very first programming lab, after only one lecture. We built a little winforms app - just a window with one button in the middle, but it minimised, and maximised, and, when you clicked the button, the background changed colour!
I was so exicited...

What languages have you used since you started programming?
Object Pascal, Java, Haskell, Prolog, C#, various escapades into scripting and general madness in Access. (Ooops, forget I admitted that... I know nothing about Access...)

What was your first professional programming gig?
Intergen! Wait, I'm still here...

If you knew then what you know now, would you have started programming?
Definitely -and sooner!

If there is one thing you learned along the way that you would tell new developers, what would it be?
Keep asking questions. Especially ones that start with "Why..." That way you get to understand why things are done, rather than just how, and you're in a better position to suggest new ideas or to implement existing ones properly and to your benefit.

What’s the most fun you’ve ever had… programming?
Playing with low-level graphics is probably both the most frustrating and the most fun thing I've done. Notably one I've done lately which takes a set of locations and routes between them for a text-based adventure game, then draws a map of the environment. (Yeah, I know, I'm a geek)

I'll tag:
JD (who's already been tagged, but hasn't done a post yet)
Duncan
Nate

How to: Code Reviews

I did a presentation on Code Reviews to the rest of our development team this morning, so I reckoned I might as well share the contents here :)

So, what's a code review?

Here's wikipedia's definition:

A code review is systematic examination (often as peer review) of computer
source code intended to find and fix mistakes overlooked in the initial
development phase, improving overall quality of software and can also be used as
a tool to better develop skills at the same time.

I actually think that's an awesome definition, but rather long winded. Here's the 'Jo Translation':

Somebody looking at your code and finding your stuff-ups – you might even learn
something!

There's a few other things that stand out in my mind as defining code reviews:

• They serve as a 'consistency check' over a project - making sure we're all doing things the same way, and following what a colleague of mine likes to call the 'design vision'.


• They're one way to make sure that someone else has a vague idea of how your code works - making sure that the project will go on even you get hit by a bus tomorrow morning.


• They're a chance to raise any issues or concerns you have - one-on-one time with your team lead, make the most of it! "I'm not quite sure how to approach this...", "Is there a better way to do this..." or even "I'm feeling really stressed right now"


• They're a learning opportunity, not just for the reviewee, but the reviewer as well. There have been a number of occasions when I've been reviewing someone else's code and have really liked the approach they've taken to accomplish something complex.

How do you do a code review?

If you can't review everything, start by figuring out what is most important to review - functionality which is critical to the system or code which is particularly complex. Once you've figured that out, sit down with the reviewee and get them to walk you through (and talk through) the code in question.

I think the easiest way to do this is: get them to close all open files in the IDE, collapse all projects in the solution view and then go through things one at a time. I know it seems petty, but it keeps things really clear and forces you to go through things sequentially and not jump around. Sometimes the very act of creating a 'blank canvas' like that puts the person into 'review mode' and can help prevent things degenerating into a simple chat about where things are at.

I'll usually try to track through a particular piece of functionality, which means that reviews tend to start at the UI and track back through the layers. "The user clicks this button, which fires this event, which is handled by this, which calls this, which goes to this web service..."

I can't over-emphasise the importance of talking through code at this level. Have you heard of the 'Teddy Bear effect'? Apparently the name comes from a university who once put a teddy bear near the help desk in the computer science labs. Students had to explain their problem to the teddy before they could ask the tutors about it. Why? Because the teddy often solved their problem.

I remember one particular student from my time as a lab tutor who would frequently come up and tell me at length about some issue he was having, only to finish with "Oh, yeah. That'll work. Thanks!" All without me saying a word...

There's something about putting the inner workings of code into words that forces us to really think through what it's actually doing, as opposed to what we think it's doing.

Anyway, back from the tangent. When reviewing code, start at a high(ish) level of design (i.e. method level) and look for things like:

• Any un-necessary duplicated code, indicating something that could be abstracted out


• Error handling


• Glaring security holes


• Unit tests - not just that they exist but that they actually cover something of value

Ask questions: Can that ever be null? What if the web service is down? Does it handle leap years? What if...

Then check for lower level bits and pieces:

• Adherence to coding standards


• Readability


• Consistency


• Commenting


• Hard coding (there shouldn't be any!)


• Sensible' code - i.e. nothing that could end up on The Daily WTF

You can also check things like logging, auditing, concurrency, performance, data sensitivity, caching, you name it. If you can think of it, and it's important to your project (or is your pet peeve) and is checkable quickly: check it. Why not?


Do code reviews early and often. They're especially important at the beginning of a project (or with someone new to the team) when you're still establishing your 'vision'/approach/whatever. Also, make sure they're done before you release anything! There are two ways to decide when to do them:

• Schedule a review regularly - this is what I do. I use weekly for most people, fortnightly later in the project and twice weekly for new grads or anyone I'm concerned about.


• Review whenever someone tells you that a task is 'done'. I haven't tried this myself yet, but an experienced colleague recommended it and I like the idea. Might try this on a future project :)

Make sure that your code review time gets included in the budget right from the start. Half an hour per person per week is probably fair - it will be more than that at the start but less at the end of the project so should average out nicely.

Why bother with code reviews?

Hopefully by now this is obvious... but just to recap:

• We're all human, we all miss things and make mistakes. A code review can pick up some of those before they hit anyone else.


• Code reviews help solve the 'our critical person got hit by a bus' problem because someone else has an idea of how your code works.


• They help ensure consistency over a project, which helps make maintenance easier, which drops the cost of maintaining software, which makes your clients happy.


• It's a great learning opportunity for both reviewer and reviewee.


• When they're done right, code reviews improve software quality enormously.


• A scheduled code review provides and opportunity to discuss any issues or concerns.

That last point has been really important to me lately - trying to lead a team of ten developers it has been hard to keep on top of where everyone is at. Scheduled weekly code reviews gave me some quasi-uninteruptible individual time with everyone to catch up and make sure everything is going smoothly and there are no road blocks I need to deal with. Since this project has been more than a little hectic it also gave me time to just sit with the team to soothe or encourage and keep things moving. Invaluable.

How do I get me one of those?

If you're a team lead and aren't doing code reviews right now - start.

If you're anybody and aren't getting your code reviewed right now - go bug someone. Your team lead is a good candidate if you have one, but if you don't, pretty much anyone will do. It doesn't have to be someone more senior than you, although more experience does help. The only real criteria for a reviewer are:

• Someone who is willing to give you advice - i.e. they're not too scared of you and aren't just going to say "That looks fine... You're so wonderful... Please promote me now..."


• Someone whose advice you will listen to - you need to respect them enough to take their advice seriously and be willing to change your code as a result.

And that's it... happy reviewing :)

Perceptions of Quality

Quite some ago Intergen's Development Steering Group (DSG, a small group of senior developers/architects) went on a 'retreat' to discuss issues affected the development team as a whole and plan some strategy. Among the items up for discussion was the issue of quality - how to achieve it, and, in order to decide that, what on earth quality actually is.

You might be thinking: "That's easy. Quality is making something good" which is all very well until you are asked to define what makes a piece of software 'good'. Is it that the code is well written, well documented, that the design is clean, tidy and understandable, that the GUI looks pretty, that the GUI is easy to use, that the system meets user requirements? All of the above?

What the DSG guys did was to take a list of eleven fairly well-accepted aspects of software quality and rank them - not at all an easy task but one that generated lots of discussion. Ranking was done by a combination of a client's view of quality and a developer's view. While the client view tended to trump all (we are a consulting organisation after all) considerations such as the ease of updates/fixes also came into the equation. Here, in alphabetical order, are the aspects they tried to rank:

• Conciseness
• Consistency
• Efficiency
  
• Maintainability
  
• Portability
• Reliability
• Security
  
• Structuredness
  
• Testability
  
• Understandability
• Usability

Before I tell you how they ranked them, let me add another interesting piece to the puzzle. After the DSG retreat, the same list was given to a group of less senior team leads (which is where I come in) and we ranked them ourselves before we saw what the DSG had decided. The resulting rankings were similar, but not entirely in agreement.

The DSG guys are more experienced, but generally far less hands-on than the Team Lead group. The Team Lead group is also generally younger and less experienced; and therefore completed their training more recently. DSGers usually work at a high level on many projects at once, providing guidance and support; while Team Leads usually work in-depth on one project at a time, dealing with the day to day issues of the team.

So... without any further suspense, here are the results:

			DSG		Team Leads
1			Security		Security
2			Reliability		Reliability
3			Usability		Usability
4			Portability		Testability
5			Understandability		Maintainability
6			Efficiency		Portability
7			Maintainability		Structuredness
8			Testability		Understandability
9			Structuredness		Consistency
10			Consistency		Conciseness
11			Conciseness		Efficiency

We obviously all agree that Security, Reliability and Usability come out on top without too much bother. In our discussion we had next to no difficulty with those three being at the top, in that order. It was a big jump down in certainty to number four - and that's where we start to see differences.

The Portability/Testability disagreement at that point is one we spent some time discussing. We thought it related mostly to a difference in perspective. The DSG see a variety of projects and are usually called in when something goes majorly wrong. Since deployment can easily go wrong, and is urgent when it does, I wouldn't be surprised if those guys see a lot of deployment issues. Also, when looking at a high level timeline of a project (or an iteration), deployment stands out as it's own phase so its importance is highlighted: Plan, Build, Deploy. Team Leads, on the other hand, tend to spend most of their time trying to get things built and resolving issues. Since Testability makes getting something built and stable enormously easier, its importance is clear.

I can't help but wonder if there's a little bit of a generational difference in there too - Test Driven Design being still a recent-ish concept, the Team Leads may have formally studied unit testing at least a little (I know it was part of my university courses, at least) while the DSG are less likely to have done so. Just guessing here.

I find the difference in where we place Efficiency interesting too: sixth for the DSG, simply last for the Team Leads. Why? I know efficiency certainly seems important when looked at on the surface, so placing it last, at first glance seems strange. However, when we (the Team Leads) were discussing our rankings, each time we compared Efficiency to one of the other aspects we came to the conclusion that Efficiency was something that could be added in later. Perhaps even added in relatively easily if everything else had been done right - reliable, testable, understandable, well structured, consistent code being easier to optimise. On the other hand, if you got the rest wrong, well, good luck getting it to be efficient! And would it still be efficient if it ran fast but it took six months to make a change? I don't know what discussions took place for the DSG, but that was our train of thought at least.

One last point I'll pull out - both groups ranked Consistency and Conciseness low (and both in that order). Obviously we all love consistent and concise code, and I hope we all strive to write it, but, at the end of the day, the other aspects did seem more important. If the code is structured well (so you can find things), and understandable, and maintainable (you can make changes in one part with breaking the others), and there are good unit tests... does it really matter if the naming or style is not entirely consistent or if some things are rather verbose? It would be annoying I'll grant you, but not critical.

To a certain extent the discussion of rankings is academic - all eleven aspects are really important and we should be trying to ensure our projects have all bases covered. However, pulling out what we believe to be most important can help us to focus and to ensure that we don't get caught up in something relatively minor and forget what really matters. I also think it's a great discussion-starter to get people talking about quality (which we all should be) and also about the different perspectives we can have that cause us to value different things for different reasons.

What do you think?

On the shoulders of rather short people

Since my last post I have done a variety of weird and wonderful things, which resulted in me being sufficiently distracted/busy/miles from a computer to forget to post anything about them! Very quickly, I have:

• Written a 50,065 word novel in 30 days as part of the general insanity that is NaNoWriMo
• Flown a glider
• Flown a small aeroplane
• Gone snorkeling at the Poor Knights (and managed not to drown!)
  
• Spent 10 days in an old canvas tent in Christchurch with around 3,500 other girls/women (Girl Guide Jamboree 2008)

Onward to the actual purpose of this post, which I hope may be more interesting!

Scott Hanselman recently published a post entitled "Standing on their shoulders and paying it forward" which contained the following paragraph:

If you have a blog, Dear Reader, why not take a moment at the beginning of this new year to write a post about the people that helped you get where you are? Parents? Teachers? First bosses? Friend? Spouse? Whose shoulders are you standing on?

The idea struck me as a laudable and sensible way to start blogging again in a new year after a long break. A list of all the people upon whose shoulders I stand would be more than long enough to cure a severe case of insomnia, so I won't inflict that on any of us. The crowd of people who have supported, encouraged and generally kept me sane over the years is huge and I am tremendously grateful to each of them. There are, however, a couple of people who stand out and have provided advice which I still quote and is helpful to more than just me.

Without further ado, may I present two women whose determination, frustration with me and patience despite it have left me with fond memories, pithy phrases and no few blushes of shame at how much I took them for granted.

#1 - a high school science teacher who placed her students far above herself - Ms Bailey

"Don't let your schooling get in the way of your education!" a hand-made poster on my bedroom wall once proclaimed. A unorthodox sentiment to have come from a high school teacher but one which proved a true and often useful guide. I had the privilege of being in Ms Bailey's classes twice - once as a 13-14 year old sitting compulsory 4th form/year 10 science, then again as a 15-16 year old in an accelerated class covering the critical sections of the 6th form / year 12 chemistry, physics and biology curriculums. In both cases some characteristics stood out: flexibility, humility and a strong focus on putting students first.

To a class of grumpy 13 year olds who didn't want to be in a compulsory science class, she posed a question: "What would you like to do in science?" To the unanimous response of "Blow things up!", she acquiesced, and found a way. A university project of mine years later began from the memory of learning to manufacture pure oxygen and hydrogen gases, measuring them carefully then taking a bottle filled with precise proportions into the middle of the tennis courts before lighting a match and watching it fly. And this despite a fear of explosions, which we only learnt about later!

To a young girl frustrated by an astronomy curriculum covering things she already knew, she granted permission to leave classes to pursue a personal project. The result sparked an interest in black holes that lasted years and left me dreaming of pursuing a career as a cosmologist and drawing singularities on paper for my friends during economics class.

Faced with a young idealist on a crusade against evolution, she again granted the permission for the project and weathered the ongoing discussion throughout the year with patience and politeness. Listening, questioning, proposing alternatives, but never ridiculing, she made the lunchtime discussions a time I looked forward to eagerly and left me feeling respected and capable. She also had the insight to use the opportunity as one of the few means anyone ever found to get me to work: if my grades dropped she quietly and simply became unavailable until they rose again.

A Biology expert struggling with the more complex Physics of the sixth form curriculum, she had the humility and grace to accept correction from a student - stunning an adolescent psyche wired to run on selfishness. Presented with my apology, her quiet insistence that she would much rather be embarrassed than allow the other students to learn something incorrectly left me more than impressed.

Having become a person in whose office I felt comfortable discussing my ideas, hopes and dreams, she shot down my thoughts of becoming a high school physics teacher with the simple statement "Don't you dare!" Again, more than a little unorthodox and certainly a surprise, but, yes, me as a physics teacher would not have worked well! In the same conversation she encouraged me to remember that there are far more areas of study in existence than those we cover in school, to try different things I hadn't thought of and thus to discover what it was I enjoyed. That approach resulted in the Computer Science and Psychology studies I enjoyed so much, and is one I advocated to a friend only last week.

For keeping me interested, pushing me to do more than the minimum, inspiring me with possibilities, pulling me up short when I needed it - thanks, Ms Bailey!


#2 - as cliched as it is, true nonetheless - MUM

All mothers, by definition, are important to their children. They all seem to accomplish miracles on a regular basis; resulting in most of them having in their possession some article or other with the legend "Best Mum in the World". Despite the stereotypicality of it, I insist on acknowledging how important my mum has been. :)

There are too many stories to tell here, but the traits I'd highlight if I could would be:

• her constant pushing for the best - for me and of me
• her stubborn independence
  
• her focus on the practical - making it happen no matter what crazy dream I came up with
• unconditional love - not only for me but for any of the wide selection of people she 'adopted'; demonstrating more than anyone else I know the ability to be there and to care no matter what a person may have done
• keeping options open - the one technique for any and every situation!
  

You want to be a nurse? That's nice, dear. Why not a doctor?

You want to be a Cosmologist? That's cool. How about we go look at how you can get qualifications for that and where you can study.

You want to be a Physics teacher? Ok... let's look at how you can do that. Just make sure you keep your options open!

You want to be an Interaction Designer? That's cool. Let's look up some universities that specialise in that. Look, there's one in London...

You want to write a novel in 30 days? I think you're mad... but, here, have some chocolate, it may help!

You want to learn to fly something? Ok, I'll give you a couple of trial flights for your Christmas present - make sure you check out all the options!

Mum has slowly become the person I go to with crazy ideas, disappointments, successes, confusion. No matter what the problem may be, she'll always be able to come up with a list of options - to check out and keep open!