The Flying Cat

A few days ago I attended a talk about software development methodologies, by Ivar Jacobson. The main idea of the talk was that the way many companies choose their methodologies is not ideal. In many companies, the software development manager (or whoever is responsible for deciding how this company develops software) looks back at the last project, thinks "we wasted a lot of time which could have been saved with a better methodology", then reads a few books, and decides, for example, "for our next project we're using Extreme Programming!" Or Agile, or Scrum, or whatever else is the flavour of the day.

Ivar Jacobson argued that this behaviour ends up throwing out a lot of the existing good practices that already exist in the company, while also bringing in a whole soup of new practices, some of which may not be right for this company. Trying to change everything at once also causes the problem that people end up being unusure of what they're supposed to be doing, nobody wants to waste hours reading manuals on the methodology of the day, and in the end, the attempt to change the company's methodology fails.

Ivar Jacobson then went on to present an alternative to traditional software development methodologies: instead of thinking in complete methodologies, look at things that must be done for all software projects (requirements, design, implementation, testing, maintenance...) and identify different "practices" or ways of doing each of these. For example, use cases are a practice for identifying requirements. Test-driven development is a practice related to both design and testing. Pair programming is a practice related to implementation.

Ivar Jacobson suggested that instead of replacing their entire methodology wholesale with a new one, companies should instead identify all of their existing practices, work out which practices are working well, and which are causing problems, and gradually, one at a time, change those practices that are causing problems.

At this point in the talk, I had a lightbulb moment. This is almost exactly the same as the personal development idea of changing one habit at a time rather than trying to take on a whole collection of new habits at once. A person who tries to stop smoking, go on a diet, and start exercising all at once will very likely fail. Changing one habit at a time helps to avoid burnout and makes the changes more likely to stick.

What's really interesting is that this idea has been around for a long time in the personal development field, and yet Ivar Jacobson is the first person I know of who has applied it to organisations rather than individual people. Which makes me wonder - are there other ideas from personal development that can be applied to groups? Are there ideas that could go the other way? This is definitely a topic worth thinking about further.

The 24th of March is Ada Lovelace Day - an international day of blogging to draw attention to women excelling in technology. This year for Ada Lovelace Day, I want to write about my mother, with a side note about my aunt and grandmothers. My grandmothers were both physicists, and my mother and aunt work in IT. It was thanks to their example that I grew up seeing nothing unusual in being the best at maths in my class, nothing strange in wanting to be a scientist or work with computers. I was only doing what most of the women in my family did.

When I was young, my mother worked on programming for a supercomputer operating system. I didn't know this at the time, of course - I just thought her work was awesome because every time I went there, I got to play games on the computers. This was around 1990, and we didn't have a computer at home yet, so this was quite a novelty for me, and the beginning of my interest in computers.

After we moved to Australia, my mother started a PhD, since it was difficult to get a job with foreign qualifications. I'm still amazed that she was able to write a PhD thesis in English, which is not her native language, while also working part time to support two children as a single mother (my parents divorced soon after she started the PhD). Her example has been a constant inspiration to me in my own studies, and remembering how hard she worked during that time makes the idea of getting a PhD myself seem easy by comparison.

As my understanding of programming and algorithms improved, and my own programming projects became more complex, we started occasionally helping each other out in our work. I helped to proofread her PhD thesis; she gave me advice on last-minute bug fixes for a game I wrote as a school project. We still sometimes call each other with questions in our particular areas of expertise. There probably aren't too many programmers who can call their mother for advice on optimising some piece of Matlab code, so I feel rather privileged to be one of them.

1. Start a blog...

Well, that's one ticked off the list!

The purpose of this blog is to get back to writing regularly, as well as to gain a clearer understanding of topics I'm interested in. I hope that having to write posts about ideas I'm thinking about will make me consider those ideas in more detail, and get me to better organise my own thoughts.

With those aims in mind, this blog will likely cover any topics I find interesting, including translation, languages, technology, personal development, artificial intelligence, and others. If one topic ends up becoming too specialised (I can easily see this happening with translation...) it may end up being split off into a separate blog. But that's definitely too early to tell for now.