Geek Philosophy

Today I did a guest lecture for CPSC 310, the software engineering class at one of the local universities that’s compulsory for the computer science degree program. I took this class when I did my degree there, and I really disliked it - it was in the process of being redesigned, I believe, and we only got through about half of the required material. At the time, it convinced me that I hated process and just wanted to keep my head down in the code. How times have changed!

The curriculum has changed since I took the course, although it is still mainly focused on traditional software engineering techniques. I was quite excited this past summer when I was asked to give a guest lecture in the class on the topic of what I do at work. I’ve spoken at schools before on the topic of Agile development, but never in a software engineering class. Apparently I did a passable job, as I was asked back to lecture this term.

I’ve never given the same presentation twice (although I’ll have an opportunity to do that soon), so I still have troubles with timing and fitting in all my content, but I think today’s talk went well. It was 50 minutes, less than half the length of the talk I gave this summer, so I had to cut out a lot of content. I know what I’d do next time to fix up the pacing, so hopefully I’ll get another chance to try it out.

Now that I’ve given a talk or two to professional groups, I actually find student groups more of a challenge. With professional groups, I can assume a certain level of base knowledge and experience, and if someone isn’t familiar with a term they’re quick to ask for clarification. With students, I’m often dealing with people who have never developed software professionally with a team. If I was talking about programming languages, that wouldn’t be an issue, but since I talk about shipping software, team dynamics, and process, I’m always scared that I’ll leave people behind. Students can also be quite timid, so if they don’t understand something they’re not necessarily going to put up their hand.

I don’t mind talking to students, and I want to get better at it, but to do that I’ll need to find a balance of easily-understood terminology and widely applicable concepts. In the meantime, I look forward to my next two presentations, both of which will be in front of professional audiences.

(Once upon a time I had another blog at a similar URL, which I hardly ever updated and which was subsequently hardly ever read. I’m posting more frequently now, but I since I have a slightly higher readership I thought I’d share some of the old posts I think still stand up. The project I mentioned shipped and was a success.

The title of this blog post comes from a Bad Religion song.)

For those not familiar with the ideas behind Lean software (and even for those who are!), please check out Competing on the Basis of Speed, a talk given to Google by Mary Poppendieck in 2006. One of my work goals for 2010 [ and 2011! - Ed.] is to compete on the basis of speed. Specifically, I want to help my team:

• identify tech debt, defects, or process problems that are increasing lead time
• minimize or eliminate the creation of new defects and tech debt
• convince stakeholders 0f the value of delivering fast to get customer feedback

I think I’m already off to a good start. The aim of the project I’m currently working on is to add functionality to our product that makes it easier to integrate into customers’ existing infrastructure. The technical requirements are known to us, and we’ve finished implementing the functionality. However, we’re at a point where we’ve hit a bit of a wall - no one on the team has any experience as a consumer of this functionality (that is to say, none of us are IT administrators), and it has been difficult to get focused feedback from others within our organization who have such experience. What it comes down to is that we’ve got a feature that is technically correct (follows RFC specifications, has been load tested, etc.) but has not been tuned to customer environments.

This is not an uncommon situation in software - in fact, it’s part of the reason why “Have an embedded customer representative on the team” is a practice in Extreme Programming. However, it’s not always possible to find internal “customers” (we call them Product Managers) with extensive experience with every particular area of the field. For larger projects it may make sense to train the Product Manager in the specifics of the new functionality by having them consult heavily with paying customers, but for smaller projects this is not always feasible. My current project is less than a month old and we’re code complete, and much of the time was over the Christmas holidays with our Product Manager (and most of our customers) on vacation, so consultation wasn’t much of an option.

So, here we stand - a mostly finished project that can be release-ready within 2 weeks but that has not been fine-tuned to meet all customer requirements (as such requirements are unknown). What to do? The traditional approach within the company has been to do a beta, but these don’t necessarily solve all problems. Our betas are opt-in, and often contain very few members (less than .5% of our customer base). Feedback can be hard to gather as beta systems are often put into non-production situations. There is also quite a bit overhead involved in coordinating and communicating with all of the customers involved.

Instead, I’m pushing towards getting this thing released to all customers as early as possible. The more people playing with it the better. The code is not buggy (we hope!), it just may be lacking some specific features or compatibility. Rather than wait around for 2 or 3 months as we do research and try to completely accurately model customer scenarios (a process that’s inevitably difficult and fraught with errors), we’ll get the code out into the field.

The best case scenario is that everything we’ve done so far is adequate for the market, and there are no future requirements. This means we’ve starting recognizing value 2-3 months earlier than if we had waited and done more market research, and we haven’t sat around gold plating the project for a quarter. The most likely scenario is that our code is adequate for some, but others will need some enhancements before it will work for them. We can then prioritize these enhancements based on some sort of financial metric (renewal date of customers who need the feature, likelihood that the enhancement will bring new customers, etc.) and deliver them over the next little while.

The worst case scenario is by far the least likely to happen - that would be where customers get the new feature, find that it’s not quite up to snuff, and because of this decide to overhaul their IT infrastructure and rip out all of our company’s products because of this. That’s so unlikely that it’s barely worth mentioning. Something like this is more likely in the case where we’re changing an existing feature instead of adding a new one, but even then it’s a slim slim chance, and would be the result of a decision on the customer’s part based on emotion rather than reason.

If you presented a customer with the choice between the following two options:

• a rudimentary version of Feature X now, with improvements to come soon afterward
• a “complete” version of Feature X several months from now

… I’m willing to bet that most customers would pick the first option. The choice would be even easier once the customer realized that the “complete” version from the second option would likely have to be followed up by a release or two afterward containing improvements that the developers / Product Management failed to identify in the first go-round.

I’m excited that there seems to some buy-in to this approach so far - hopefully it pays off for us!

For the past two years, I’ve been managing a software team. This role has a lot of requirements, and I think I’ve been fairly successful, but there’s one thing I used to do that I never really do any more - program. Sure, I review a lot of code, and occasionally pair with people or help problem solve, and when asked I give my opinion on architecture, but it’s been a while since I’ve sat down with some code to myself and tried to get something done.

Well, I’m trying to change that. I’ve realized (through a few false starts) that I’m not going to pick up a new programming language, hop into an open source project, and start contributing. I think I have the ability to do so, but definitely not the motivation. Instead, I’m going to chip away at small improvements in my product’s code base that will hopefully make life easier for my team. For now, I’m going to stay away from changing a lot of production code - I want to ease myself back into the groove slowly, and while I’m not afraid that I’ll write a bunch of awful code and ship to customers, I don’t want to get too bogged down in our automated test rig at the moment.

I’ve got two little projects going on right now. The first is to add Perl::Critic tests to all of our packages. Perl Critic is a highly configurable automated code style critic, inspired by Perl Best Practices, that can help you detect all sorts of wrongness in your code. It’s easy to add a test, and then a lot of fun (for various definitions of “fun”) chasing down all the failures and getting your code up to snuff. I’ve only added the test to one package so far, but it’s a package with over 100 files so it took me a while to clean up. Subsequent packages should be easier, and it should be self-enforcing going forwards (as all of our tests are required to pass before a build is produced).

The second project is to ease our use of CPAN modules by rewriting part of our build system to use cpanminus. Our current system makes it difficult to import CPAN packages, or even upgrade the ones we have easily, so I think this could really benefit us. Replacing some of the packages we’re still using from 2002 would be most welcome, and there’s a lot of exciting stuff being developed for Perl right now that would be ncie to experiment with. So far I’ve got just been playing around a bit with cpanminus, but I’ve already managed to find a bug (I think - I’ve filed it anyway). I may write more on this once I’ve got it working.

These aren’t exactly monumental bits of code I’m fiddling with, but it feels good to get back into it, and the important thing is that I’m actually motivated to do this coding. I have no desire to go back to being a full time developer, but it’s nice to keep up my technical skills.

A quick Google chat with a friend of mine today about his company’s implementation of Kanban got me thinking - how many people out there who say they’re using Kanban actually know what it is? They may know there’s a board, and maybe some limits, but is that it? Of course, I can’t change what people in general think, but I can certainly work to influence those around me. This post is part of that effort.

Kanban is pretty simple (with respect to core rules / definition), but it’s not as simple as “just put up a board and some numbers.” Just visualizing your workflow can be a catalyst for change, but a Kanban system needs more than that. Straight from the horse’s mouth, the core practices of Kanban are:

1. Visualize the workflow
2. Limit Work-in-progress
3. Measure and Manage Flow
4. Make Process Policies Explicit
5. Use Models to Suggest Improvement Opportunities

This is coming from the guy who literally wrote the book on Kanban and has toured the world popularizing its use, training people, and watching Kanban successes and failures. 

My friend’s company routinely violates WIP limits (“it’s been this way for several months” or something to that effect), and that never provokes a discussion about changing the limit or analyzing the cause of the broken limit. Product management has not fully bought into the system, seeing it instead as a generalized queue. Developers are rather independent (no development manager), and apparently sales has not been pushing for any SLAs, so no one has bothered to analyze flow, measure lead / cycle time, or anything else that can drive toward systematic improvement based on what the board is telling them.

Now, this is not to pick on my friend’s company - he’s a bright guy, as are others he works with. I’ve seen this within my own company as well. I routinely walk by other people’s Kanban boards and say “Hrm, WIP limit 4, 5 items - what’d you decide to do about it?”, which usually prompts some action. Some teams are trying to implement specific policies / standardized work, and I’m the only one that I know of trying to analyze lead and cycle times. Even there, I’m not doing everything that I could do. And yet, I still here Kanban being touted throughout various bits of the organization as “the next big thing”.

Why does any of this matter? Well, it doesn’t, really. Unless, of course, you actually want to get the most out of your system. Presumably, these teams adopted Kanban for a reason - they liked the idea of flow, had seen success stories, and wanted to see what they could do to improve their organization. Is that not still the case? Using Kanban “properly” isn’t that difficult technically, it just requires a bit of buy-in, social capital, and a willingness of people to examine the situations they find themselves in and look for improvement. It doesn’t personally bother me if you’re doing Kanban “wrong”, any more than it would bother me if you were a birth-control using Catholic or a beer-swilling pork-eating Muslim. I just think that Kanban, when used properly, can be a very powerful change catalyst, so if people have a passing interest (enough to adopt the term “Kanban”, at least), I’ll help them out if they want me to.

As previously mentioned, I’ve got a talk coming up for a UBC class. This is the required software engineering class in the UBC Computer Science program, and a class I vividly remember as being a waste of my time. Fortunately, the course content has changed quite a bit since I took it - after four months in this class, I came out with a 25 page specification package and no code written. It was one of my least favourite classes, and it convinced me that I didn’t care at all about process (how things have changed!).

I spoke at this class during the summer, but I plan to deliver quite a different talk this time. Part of this is time - this summer I had two hours, and two weeks from now I have half that. Time isn’t the only factor - the more fundamental difference is in the content. While the talks I’ve given to previous classes before have been rather broad overviews of Agile (and more recently Lean) concepts, this time I’m going more with what I know best. That means less theory, and more description of how my team successfully delivers software. I’ve talked to the class instructor about this and she also thinks it’s a good idea.

I’m still finalizing an outline, and I need to make sure I present this at a level that’s approachable to a class of students who likely have no real (professional) software development experience. I also hope to find time to polish my slides, and make sure I’m not just reading list after list of bullet points, but I’ll have to see what time permits.

Even though I work for company that has millions of end users and is one of the leaders of its industry, whenever I tell people where I work I’m met with blank stares. Why? Unlike some of our competitors, Sophos doesn’t sell directly to consumers (you won’t find us for sale at Best Buy, nor are we bundled when you buy a Dell) - we only sell to business, governments, schools, and other organizations. Thus, blank stares. Luckily, Sophos has come to my rescue and released a great free tool that’s already raised their profile among non-business users - Sophos Anti-Virus for Mac (Home Edition). Best of all, this release is free!

Now, I know what some of you are thinking - why would I bother with anti-virus for my Mac? Well, Macs are not immune to malware, and they can host Windows malware that can infect friends and family. Sophos Anti-Virus for Mac is featured on Apple.com, is mentioned as a staff pick, and has been positively reviewed in several places. I’ve been running this for a while, and it’s hardly noticeable, even though I have hundreds of gigabytes of files on my Mac. The one time where I did notice it is when I downloaded a “demo” of a program (a torrent of something that I wanted to see the interface for), and it immediately detected a keylogger in one of the files.

If you have a Mac, there’s no real reason not to be running this.