Geeky

I’m so sorry, but I just have to rant about this: The last few years I have been part of organizing an IT-conference here in Aarhus called JAOO. Last year, when the world was in crisis mode, I could understand why people, when asked if they want to go to JAOO, said, that their boss wouldn’t let them and that the conference budget for the whole year was cancelled.

This year the economy is doing much better and still my friends are not going to JAOO even though they love the conference. Now the excuse is that they don’t have time. Fewer hands are doing the same amount of work as before the crisis, so now they are running around getting sick from stress. AND they just accept that their employer does not update their skill set because the business is too busy.

I can let you in on a little secret: The business is always busy when there is no economic crisis. Some IT-companies was even busy when the crisis was peaking. Such is IT. The diffence between now and then is that now the workers that did not get to go to the conference last year and probably wont get to go this year are outdated. They haven’t taken the time to get their qualifications updated the last few years and the tech world is moving terrible fast. Some don’t know what the whole NoSQL-thing is about, some haven’t heard much about HTML5 and some haven’t heard anything about the mobile phone development department. Now the crisis is over and companies are getting business deals that demands skills in that department and their current workforce can’t deliver. They should have been working smarter, not harder!

A lot of places they are trying to bring in new people with updated skills but this is turning out to be problematic. New workers have a learning period before they can get really started and sometimes you end up hiring the wrong guy/gal for the job because none of the people who applied was right for the job. Firing people is also expensive (at least it is here in Denmark) and if the current skill set in your workforce is outdated then you might have to.

I just think that it is very irresponsible to accept being outdated in the tech knowledge department – it could lead to unemployment. When my last employer told me I couldn’t go to JAOO, I decided to pay for the whole thing myself by taking some of my vacation during the conference (I got the ticket through version2.dk because of my blog there). Of course now I don’t have the problem of having to use my vacation time on conferences, because I quit my job to travel the world… (I’m leaving just 2 weeks after JAOO and yes, that timing is chosen on purpose.)

I’m so sorry for the rant – soon I will be back to normal and overly positive as usual.

(P.S. Of course there are plenty of ways to keep your skill set updated – I just know the conference business especially well, so I know that those few days are well spent, very inspirational and valuable enough to miss a few work days.)

Our industry is plagued by an epidemic of very bad code

– Robert C. Martin (known as Uncle Bob), founder of ObjectMentor and author of several books including Clean Code: A Handbook of Agile Software Craftsmanship.

Of course Uncle Bob would say that because it serves his purpose of selling the Clean Code-book, but I would still agree with him on this one. I often hear a lot of programmers complaining that in a world of perpetual recurring short deadlines there will be a lot of technical debt and code debt in our line of work. Unfortunately.

But what can we do about it? There is never time for a spring cleaning and the business usually can’t see the point of such an activity, but hey, they are not the ones having to live in that messed up codebase.

Sometimes I even hear the technical debt argument as a anti-agile argument – because an organic not-designed-up-front architecture is inevitably going to end up with a lot of technical debt IF NOT REFACTORED on a regular basis. My answer to that, is that refactoring is a part of any agile programmers job – your story is not finished before you have refactored the code and considering architectural refactoring should be part of sprint planning.

A similar point is made by Uncle Bob in this video from the IT-conference JAOO (about 7 minutes in);
When Uncle Bob asks Pete McBreen how a programmer can get the time to write good code and his answer is: “you should cheat the boss – just write good code without permission to use the time”, Uncle Bob comments, that he doesn’t consider that cheating – he considers that professionalism!

I still believe that an organic REFACTORED architecture is better than an up-front-planned architecture, that is outdated and worked around when adding new features.

Is your work also impeded by bad code? Do you consider it professionalism to cheat your way to a liveable codebase?

P.S. Michael Feathers (also in the video) just wrote a blog post about learning from bad code. Please consider helping him with this project.

I no longer believe in doing Scrum by the book!

This will be considered a provocative statement for some but let me just explain myself: I’m not suggesting that we shouldn’t follow a well-defined, tried and tested process, but I AM suggesting that we adapt the process to our current needs and maybe as far as you couldn’t call it Scrum anymore.

Now some seasoned agile people will say “DUH, of course you have to inspect and adapt. That is what agile is all about”, but I have also heard a lot of people saying, that “of course that project failed – they didn’t do Scrum properly” (whatever that means).

In my opinion what matters is that you reflect on you proces and continuously improve (Kaizen) – if you do that you can start out with Scrum and adapt into something that is a better fit for your organization. It is much easier to fit the process to the organization than to fit the organization to the process.

At JAOO last year I attended a tutorial called “Scrum tuning using Organizational Patterns” (by Jim Coplien and Gertrud Bjørnvig) based on the book Organizational Patterns of Agile Software Development by Jim Coplien and Neil Harrison. It transitioned me into what I jokingly call my post-Scrum phase – a phase where I can see agile as a collection of good ideas to choose from; a toolbox. The organizational patterns book adds to that toolbox and provide ways to guide the adapt part of inspect and adapt.

Now I have the feeling that I know more about why Scrum is precisely that collection of good ideas (organizational patterns) and what kind of problems Scrum is aiming to handle and that feeling gives me the confidence to reflect on the Scrum method and adapt to the concrete needs of the projects I’m involved in.

As Jeff Sutherland writes about Jim Coplien and the Organizational Patterns-book:

Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes. It takes over 60 pages of rather dense text to describe these patterns.

The connection between Scrum and Organizational Patterns can be seen in this overview that I stole from the slides by Jim and Gertrud:

I recently found a link about the Top 10 Organizational patterns – As far as I can tell they are presented as in the book, but the links to other patterns are dead links (and remember; content is more important than form in this case).

Organizational patterns have really helped me move beyond Scrum and to value some of the more social aspects of software development higher. If you are having problems with your process consider looking into this concept. I know that patterns are sooo 90’ties, but they are still a reasonably way to transfer knowledge.

And I should probably revise my first statement – I no longer believe in doing Scrum by the book, but I do believe that a book can inspire me to fine-tune Scrum maybe transforming our process into something completely different – if that is what we need.

Back in December ’09 a friend of mine and I decided to found a community for women working in IT in the Aarhus area. We named this community Ada Aarhus after the famous female “programmer” Ada Lovelace. The idea for this community started at a geek girl themed night at the JAOO conference in October ’09.

The community started out with three main focus points:

1. Recruiting more women to work in IT (presenting role models and work on concrete projects)
2. Coaching and mentors (facilitate the contact between mentors and mentees)
3. Networking (share stories and network in the IT-business in general)

And in addition we defined what Ada Aarhus is NOT: a place to go and cry about being a minority in the IT-business. The women in Ada Aarhus love to be in IT even though we are not shy about talking of the problems that arise being a minority.

The first meeting was set up through Facebook and we invited all our female geek friends and they invited their friends and so on and we got the local union to invite their female members… We were 10 women at this first meeting, WOW. We decided to meet every two months and after a couple of meetings we elected (asked) some people to run this community with more than 50 members on LinkedIn and almost 50 members on Facebook.

Now we are on Facebook and LinkedIn and we are working on a network site with blogs, messages and profile pages, so that we can network online as well as offline. Any woman living in the Aarhus area willing to call herself a woman in IT  is welcome to join us on LinkedIn or Facebook.

I have recently sold a Twitter explanation video to a communication company. Doing that I ran into the problem of sending the really big video file to the people that bought the video. I tried Dropbox (another great site) and the receivers could see the video but not download it. Then I found several file sharing services but you had to sign up first and accept their spam afterwards. Not really what I was looking for but I was in a hurry and it solved the problem though not entirely satisfactory.

Now I know that filesharing can be much simpler. One of my friends at the university made a site that adresses that file sharing need in the most elegant way. The site is called Kkloud and works by keywords – you type in a keyword and if someone has shared a file on that keyword you get access to it – if not you can share your own file on that keyword through drag and drop. Now you can share your files with your friends – just share the keyword.

The really cool thing is: the files are only shared as long as you keep the sharing window open. When you close the window they disappear.

The team behind Kkloud made a video to explain this – watch it just to convince yourself that it really is that simple:

I think there are several lessons for programmers to learn from Kkloud:

1. Simple is better. (“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery)
2. Limitations can make your site stronger. Twitter is another example of this.
3. Even if your idea has been done before, you can do it better

And of course in wishful thinking of any programmer “if you build it they will come” – I surely hope that it turns out to be more important to have built a cool app than it is to have a great business plan. Get the big user base and there is income to be had from that app.

Kkloud recently won the Software part of the Venture Cup and it earned them a well-deserved 50.000 DKK. Congratulations Kkloud – I wish you great succes with your business.

Working behind the scenes at the JAOO conference the last few years has been a great inspiration for me. I have met great conference speakers like Linda Rising, Michael Nygard, Mary Poppendieck, Jim Coplien, Ola Bini, Dan North and many more that I really respect and admire. This year I left JAOO for a glamorous job as a full-time programmer and even though I can’t wait to go back and experience JAOO from the other side of the fence I must say that looking at this years JAOO speaker lineup, I am less than impressed. My favorite speaker Linda Rising is not coming and even though the usual suspects seems to be there except Linda I’m just not as excited as I have been the other years I have attended JAOO.

One of the first things I noticed was that in general there is not many female speakers on the program this year. I would have liked to see names like Rachel Davies, Aino Vonge Corry, Linda Rising, Rebecca Parsons, Amanda Laucher, Gabrielle Benefield and maybe even some new female names up there with all the guys. And usually there is quite a few female speakers at JAOO – even a few obscure cool female geeks and not just the cool authors of geek books – just not this year. Weird. And yes, I know I’m one of the few that notice this gender disparity but as a geek girl you are always looking for new geeky role models.

The second thing I noticed was that JAOO doesn’t seem to be featuring a lot of talks about topics from every day life as a programmer. I am a Java programmer by day and a C# programmer by night and both C# and Java seems to take a backseat to the more obscure languages at this years JAOO (but you could argue that this is a continuing trend from the last few years). There is no pure .NET-track this year but a “mainstream languages” track where Java, Javascript and C# can battle for the presentation slots. And they couldn’t even fill one track with mainstream languages – they put F# in there too. I could only count 9 presentations tagged with .NET but a few of them can’t be called .NET-topics – they are just vaguely related. The Java side of things looks a bit better with Spring-topics,  Android and of course all the languages built to run on the JVM like Clojure and Scala.

Of course this is all concerns I have with the conference schedule as it is now – things can look quite different in October when the conference starts. There is still open presentation slots on the schedule. And even with a less than JAOO average lineup this years conference will probably be much better than the other developer conferences. I love JAOO!

See you there?

P.S. I will even forgive the team behind JAOO for chosing a pink venus sign as the logo for my usergroup Ada Aarhus, but only because we haven’t chosen a logo for the group yet. The sign of venus is just a bit too cliche to use for a usergroup of geek girls.

P.P.S. I call Ada Aarhus my usergroup because I co-founded the group back in December ’09.

Just as I am a Scrum fan I am also a fan of the Pomodoro technique. The Pomodoro technique is a personal time management method inspired by agile practices such as the backlog, the sprints and making the work priorities visible and explicit. Pomodoro means tomato in Italian and the Pomodoro technique was developed by Francesco Cirillo.

A short explanation of how you use the Pomodoro technique to manage your day:

In the morning you make a backlog, prioritize it and estimate it in number of Pomodoros. A Pomodoro is an uninterrupted time span of 25 minutes.
Then you start work: work for 25 minutes then take break – if you are interrupted handle the interruption in a number of specific ways depending on the type of interruption.
Write down how many pomodoros you use on every task and make notes about interruptions.
At the end of the day take some time to reflect on what you have done, how long it took you to do it and what you could do better, document and put in an archive.

This is a great technique to use if you are coming home from work not sure what you have accomplished and how your time was spent. This way you make sure to document your day, think about your priorities and compare them to your actual work done. The data collection side of this technique can also be used to assess the consequences of a change you have made to your habits or working environment.

You can read more about the Pomodoro technique in this free e-book written by the originator himself. He has also made a cheat sheet useful for talking to colleagues or friends about the technique:

As this technique is quite popular with software developers there is a lot of software implementations to assist you in using this technique: several iPhone apps and versions of the timer used to measure the 25 minutes.

I have used this technique when I had to write my thesis at the university and it worked well for me. The e-book is easily read and even though the technique is difficult in practice, the learning curve is not steep. The first pomodoro was the hardest one but the technique was easily picked up. Maybe you should just try it – I would love to hear your experiences.

This weekend we decided to attend the Aarhus Startup Weekend, which is part of a whole network of Startup Weekends all over the world.

We are now at the end of day two. Yesterday the 60 participants pitched 38 ideas, we voted and 10 ideas was chosen to compete for a 10.000 kr. first prize. Right now we have a clear image of what we want to present on Sunday evening and us coders in the team are working on some demo software (just a proof of concept). The PR/idea/marketing/business/presentation/vision people are working on a video of our whole concept for a later pitch presentation and of course I found the time to write this blog post for you.

The team behind Aarhus Startup Weekend also made sure we will remember the experience – StikIRendFilm has captured the experiences from the first day in a video.

Our team decided to work on a concept about event planning on Facebook – focusing on going to the movies with your friends. It is going to be very cool and innovative and hopefully we have something to show people here at Startup Weekend on Sunday evening.

Often tasked with explaining Scrum to people new to it, we have debated thoroughly about the essentials of Scrum. What should you focus on? In a short presentation you do not get the luxury of being exhaustive and tailoring the explanation to the person you talk to is a great strategy but when speaking to a larger audience not always an option.

Well, a quick Internet search answers the question with a Scrum Cheat Sheet. It sums up the key elements in Scrum without getting you bogged down in details. Of course this is not enough to teach someone Scrum but it can serve as a great conversation starter.

There are several of the short points on the cheat sheet that deserves highlighting even to functioning Scrum teams and that is a testimony to the quality of the points.

The two points that are actually highlighted with a different color are some of the vaguer points about Scrum: “DONE” = potentially shippable and Visibility+flexibility = Scrum. Not neccesarily the MOST important points about Scrum but maybe the author of the cheat sheet has some experiences that makes these points especially important to her.

Personal experience makes me focus on the following:

• the responsibility of the Product Owner,
• that items on the product backlog can be added by ANYONE,
• that functionality not done is not shown at the sprint review

I would probably have added to the part about retrospectives that they are not about assigning blame (a simple but in practice difficult rule). The explanation about story points is also a bit off compared to my experience and I would have mentioned planning poker, but I can live with the current form of the cheat sheet and applaud the author for making it. Nicely done!

What would you have highlighted? Does the Scrum cheat sheet match your take on Scrum?

Lego is the greatest toy company ever and I’m not just saying that because my husband works for them. He and I have both played with Legos as children and kept playing until now… Even though there is officially no children in our household we both would qualify as children when it comes to Lego. Our passion for bricks is not ours alone; We know a lot of people who love Lego bricks.

The computer science department at Aarhus University (my old hangout) has a Lego Lab and many fun og cool projects has come out of that lab the last 15-20 years – some more serious than others. A fairly recent project is especially close to my heart because it was done by a group of my friends. It is… wait for it… a Lego Turing machine!

To promote it they made this short video:

Geeky and beautiful!