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?

TechEd Day 3

It's amazing how fast three days can go when you've having fun and trying to learn everything there is know about everything in one hour sessions! But, the end has come, TechEd is over and, one hour later than the flight was scheduled, I have arrived back in Wellington. I will put together some 'lowlights' and some more detailed notes once I'm a little more awake but in the meantime, here's the highlights from today:

• Lukas Svoboda on Development Teams was interesting for the first half when he was talking about principles of building great teams and how to recognise them, but less so when he moved on to telling us how great Team System is, at length. Shocking moment for me - he asked the audience "Who's used continuous integration builds of some kind?"; the entire Intergen contingent put their hands up... and about 2-3 other people. In a crowd of probably more than 300. I can't imagine working without my CCTray... what are people doing?
• Andrew Peters on .NET Languages took us on a quick romp through static, dynamic and functional languages in the .NET platform. Andrew covered a lot of ground in a hour and kept it interesting with lots of demos. He finished with a challenge to go learn a dynamic language - that's been on the I-really-should-get-around-to-that-sometime list for quite a while, must do that. Python or Ruby anyone??

Overall, TechEd has been great. While some sessions have been decidedly uninspiring, they're in the minority and I've been able to hear a lot of good stuff on a huge variety of topics. I have been reminded again and again of two things in particular:

1. As I've mentioned previously, how passionate I used to be about User Experience design, and how much I should be again.
   
2. How much knowledge we have at Intergen that we take for granted but that a fair proportion of the industry doesn't seem to have picked up on yet e.g. continuous integration builds, test driven design, the MVP pattern... Our management often say we're ahead of the game, TechEd has served to prove to me that it's true.
   

If you get a chance to go to a TechEd anywhere - go. :)

TechEd Day 2

I'm half asleep as a result of the TechFest party last night so if this doesn't make much sense I apologise...

Highlights from TechEd New Zealand day two:

• Shu Scott on SQL Server 2005 optimisation was a usefully practical set of best practices to ensure queries run as efficiently as possible. Packed with content and some good explanations of why things work the way they do. I'm fascinated by the way the query optimiser chooses query plans, something to look into more.
  
• Joel Pobar on C# 3.0 - probably the 'geekiest' session I've been to so far and was tremendous fun. Looks like there's lots of cool new features in the next version of C# to make our lives easier and coding faster. Auto-implemented properties and initialisers and type inference I'm sure I'll be using as soon as they're released. We also implemented LINQ from scratch in about 15 minutes which was a great romp through the new features. I'm particularly looking forward to playing with LINQ.
• Jeremy Boyd on SQL Server 2008 - lots of new features here too, and again often around making life easier and faster. Being able to insert multiple rows from a single INSERT INTO VALUES statement will make creating test data rather less painful and the new MERGE statement will also be used a lot I'm sure.

Overall, very 'geeky' day yesterday but good fun and plenty of things to continue playing with a investigating. Downloading SQL Server 2008 CTP and having a play is definitely on my to-do list once I'm back home.

TechEd Day 1

So far, so good. With one day through and a second just beginning, TechEd New Zealand is looking to be a great few days.

Highlights thus far:

• Keynote from Lou Carbone on the shift from 'make and sell' to 'sense and respond', experience engineering and being 'clued in'. Lou was not just saying good stuff but saying it well, keeping to audience engaged and laughing. My favourite quote: "Businesses exist to provide value to customers. The reward is profit." The implication being that profit is merely a side effect of accomplishing the actual purpose, the focus should not be on profit but on customer value. I had a great (if brief) conversation with my manager afterwards talking about how we all need to be reminded of that sometimes.
• Grant Paisley on Analysis Services was a very geeky and good fun session from a presenter who knew how to make sure people remember what he says. He had the audience with their hands in the air doing actions for each of his main points... "Attributes (wiggle fingers), attribute relationships (cross fingers), consolidate dimensions (hands together), partitioning (karate chop your neighbour)"
• Darryl Chantry on UX Design served to remind me not only of how passionate I was about user experience while I was at university but also how much knowledge I picked up in the process and take for granted. A lot of the good points Darryl made (e.g. good design is invisible, users want predictability) my colleagues were commenting on as new and exciting while I'd heard them all before... Inspiring session with lots of examples of design the way it should be.
• Women in Technology dinner brought 150 women from all sectors of the technology industry together for some good food and networking. It was a good night, although many of the audience didn't entirely agree with some things that were said (more on this later I'm sure!). Favourite quote was Helen Robinson's (Managing Director Microsoft NZ) comment that "The best teams are made up of the most varied people."

Overall, it's been fun and informative with lots more still to come. The yellow camo pants are actually pretty comfortable and we're certainly hard to miss - come and say hi if you're around.

In need of people

Intergen now has its own blog (with a post from me, which is a little scary!). I'm thinking it will be an interesting one to watch - should have posts from a variety of people on a variety of topics but generally covering the organisation/industry wide type issues that I find interesting.

That's my plug for the day :)

We've had some interesting discussions around work lately around the male:female ratio in IT and whether it needs changing; following on from my previous blog posts, the post from me on the company blog and our recently acquired membership to Women in Technology (WIT). One conversation (which went on for an hour!) with a couple of other women was particularly interesting. I was asked: "So why do we need women? Do we actually have anything in particular to offer other than numbers?" and it was also pointed out that "The IT industry just needs people". True. And, I think, exactly what I've been trying to say.

I'm aware that there's a fine line between helping things shift equality-wise when they need to, and making too large a fuss that only creates new problems and I want to make very sure I'm clearly on the right side of the line. So, in the interests of clarity and not being lynched, here's a quick summary of where I stand:

The IT industry needs people to work in it but, for some reason, half the population are far less likely to than the other half. There's no particularly good reason why this difference should exist to this degree so, as far I'm concerned, it shouldn't. But, it does, and there are some bright young women out there who would probably really enjoy an IT career but don't think of it as an option. That's not cool. I'm not a crazy women's-rights activist, but I am passionate about young people getting all the opportunities they can to excel. If I can do something to ensure that girls are leaving school with a good grasp of the choices they have of where to head next then I'm all for it!

We need to promote IT as a career to people. Not women. Not men. Just anyone and everyone who has the aptitude and might enjoy it. However, whatever we're doing at the moment seems to only be reaching the men... and that's what I think needs to change.

(Incidentally, the other thing I think may need to change at the moment is for me to stop being the 'womens advocate person' and go back to just being a developer...)

Developing Girls - 2

Following my previous post, it is worth noting that we have lots of female analysts and project managers. They may even outnumber the guys in those roles and quite a number of them are ex-developers.

So it would appear that women tend to move out of development roles into more direct people-facing roles. Why? I think development is much more fun... But maybe I'm just odd. I guess it's another reflection of the same need to be 'helping people' directly that keeps girls out of engineering/software development to start with.

Thinking of possible reactions to these posts I came up with a couple worth addressing:

1. So? Who cares?
2. But girls don't have the logical brains for coding, they don't get into development because they just can't do it. Simple.
   

The question of who cares is easy to answer: anyone who has complained about the general shortage of developers. If we want to increase the number of capable developers out there, not cutting out half the population is probably a good starting point.

As for the second objection - rubbish! I know four women who disprove that every day. Unfortunately I can't leave it there because I am enough of a psychologist (yes, I have a psychology degree) to understand that there are differences between the way men and women think. A major one of those differences relates to aptitude for mathematics and the pure logic necessary for good programming. Guys are better at it in general. However, 'in general' does not mean there aren't plenty of women out there who have that aptitude. No, there aren't as many as there are men; but the number differences aren't anywhere near as large as those we see in the industry.

So those male-female ratios are something we should change and something we can change. Lets do it! If you have a chance to speak to a smart young woman anytime soon, make sure she's considering IT as a career option and show her she can make a difference.

Developing Girls

This post was going to be about how junior developers can learn from the senior devs on the team. However, as I was mentally composing the first few sentences, I realised I was using exclusively male pronouns to refer to said senior developers. A moment's thought on why I was doing this revealed that we have no senior female developers.

In fact, there are a grand total of four female developers in our entire development team, three of whom started working for us as new graduates in the last three years. The fourth, admittedly is recognised as a senior developer, but our group of top senior devs/architects (the 'Development Steering Group') who I was going to talk about learning from are entirely male. To give you an idea of just how shocking these numbers are, our development team in Wellington probably includes upwards of 60 people. Once you add the other offices into the mix the number tops 100 and, from memory, I don't think there are any more women. 4% is a pretty dismal figure!

Don't get me wrong here - I do not for a moment believe that the company is discriminating at all. There just aren't many female developers out there to be hired! The situation was the same studying at university - it wasn't unusual for me to be one of two or three females in a class of more than 60. Female devs have sometimes gone to some fairly extraordinary lengths to assert their presence but nothing seems to be changing.

This reminded me of a blog post I read earlier this year about an article on cnn (unfortunately the link to the original article is now dead) about why women don't get into engineering. Apparently women aim for careers where they feel they can help people, hence the traditional female domination of roles such as nursing or teaching. I had a very close to home example of this recently when a younger friend who'd always aimed to be an accountant decided she never wanted to work for an accounting firm because it couldn't possibly be fun. "I'm a people person, I need to be working with people not with numbers." No amount of explanations could convince her that the numbers would be helping people, that she'd be part of a team, that any job was a 'people job'.

Now, I have nothing against wanting a career where you feel you're helping people - that was, and is, my aim for the work I do. I wouldn't be able to get out of bed in the mornings if I didn't feel that something I was going to do that day would help someone. My actions are focused around helping my clients get software that will make their lives easier and helping my workmates to be happier and less stressed. Yes, I spend most of my day staring at a computer screen; but my job is definitely a 'people job'. I originally got into IT after spending some time working as an admin/helpdesk person and seeing how upset and frustrated computers made people. I got to thinking that maybe if I could help create computer programs that were easier to use the world might be a happier place...

A lecturer in one of my university software engineering papers spent one of our ethics lectures discussing the lack of female developers. Her theory was that most guys get into IT through being interested in computer gaming. The problem is that most computer games, having being designed by men, don't appeal to girls; so the major entry point doesn't apply. Please note I said 'most' - there are exceptions (I'm a big fan of Myst and I have a friend who loves The Sims) but as a general rule gaming is considered to be a male activity.

So what do we need then? For games that appeal to girls we need game developers who understand what girls want to play and are willing to take the risk of trying to develop a new market. But, more crucially I think, we need to educate young women about all jobs being 'people jobs' and the opportunities there are to make a difference in the IT sector. I was talking to my high school computing teacher some time ago and we discussed the possibility of me talking to her classes. Maybe I need to get in touch with her again...