Ignite Waterloo

Yesterday, I got a chance to go to Ignite Waterloo 6, a community event where people give 5 minute talks on topics they're passionate about.

As always, it was an excellent event. It's fun to see some of the same faces at all the community events in Waterloo.

There were some notable talks. Cate Huston gave a talk entitled "Why Do Programmers Have to Lie to Get Dates?", where she claimed software developers have a communication problem that we need to address. There is a lot of confusion about what software developers actually do, and it leads to some interesting questions like "So you work for the internet?". If we figure out how to communicate better, not only will be create better software, but people will understand what we actually do. :P

Syd Bolton talked about cool uses of old computers. He is one of the founders of The Personal Computer Museum.

Bob Rushby, ex-CTO of Christie Digital, gave a talk on the how the future will be full of pixels. He imagined a world where everything analog will be replaced with something digital. Cool stuff.

Ben Brown gave an interesting talk about getting rid of all road signs. Apparently some places in Europe have done this with great success. I'm not convinced that this would work in Canada, especially in larger cities.

Steven Scott debunked the "I've got nothing to hide" argument on Privacy. Also an interesting discussion.

To finish the night, my good friend Amal Isaac gave a great talk on The Technological Singularity. He talked about an interesting future when, inevitably, computers surpass our intelligence.

All-in-all, it was another great event in the KW community! :)

Importance of Data Visualization In Agile Teams

I went to an Agile P2P meeting after work today. The speaker was Jason Little, an agile coach. He seems like a very interesting guy. I like how he doesn't seem to get bogged down by what "agile" says you should do, but rather he focuses on getting actual results. It's refreshing to see.

Anyway, he was talking about the importance of data visualization in agile teams. By displaying data in concise and intelligent ways, major problems become much more evident. Problems that are hidden by poor data presentation can become glaringly obvious when you display the information in the "right" way. Uncovering these problems is a huge part of improving what you do as an organization. For example, take stories in your electronic issue tracker. If you have a lot of bugs in your issue tracker, you might not see it right away because of the way they're organized. If instead you put all your issues on coloured sticky notes on a board, and you see a clump of red tickets, it becomes immediately obvious that your software development process might have serious quality gaps. If you further organize those tickets by time, you can visually see when a lot of those bugs were discovered (and can guess when they were introduced).

The importance of data visualizations doesn't only apply to agile though. Data visualization is important in a lot of fields. Humans suck at looking a unorganized data and making sense of it. Computers are much better at this. Data visualization will be very important in the future to help humans make sense of the immense amount of knowledge available in some fields. Like in the agile example above, some problems might become glaringly obvious if you organize and display the information in the "correct" way. The cure to cancer might be hiding in the data, and it's just a matter of showing it the right way before it jumps out to someone.

Okay. I'll stop procrastinating now and finish off that work report.....



....



or watch Community.

UW REAP

Now here's something cool: UW REAP.

Basically, companies give students an opportunity to find new, innovative uses for their technology. Students do it as a part time job on top of their course load. Not only do the students get great experience working with very cool technology and companies, they also get paid! The program also contains project management training for the students. Getting this sort of hands-on experience in industry is invaluable for students.

I think it's a fantastic opportunity and I'm really happy to see Waterloo do something like this. I will definitely be applying for next semester. My only concern is doing this with Real-Time. :S

Product Sashimi

Yesterday, I had a chance to go to my first Agile P2P meeting. The talk was on Product Sashimi, and how to "slice a thin product" by J.B. Rainsberger. The main point Rainsberger was making was that there are benefits to be had by breaking up a large project into several smaller projects.

He started by defining 3 values of software. The first is features. This is what most business people refer to when they talk about business value. The second value of software is design. If a piece of software is poorly designed, the cost to add features to the system increases very quickly. Eventually, the cost of adding new features surpasses the cost to simply rewrite the software from scratch! Rainsberger affectionately refers to this as "Product heat death". I lol'd. The third, and main value Rainsberger talked about was how long before a customer can say "not what I wanted".

The sooner we get to that point, the sooner we know that the project is off track. He also mentioned the 80/20 rule for software features. Essentially, 80% of users will only use 20% of the features. The version that he stated was that only 20% of your features will be used often. The other 80% will be used rarely. 

Rainsberger says that if you "slice" thin products, you are more likely to get to the "not what I wanted" stage sooner. If you get to the "not what I want" stage sooner, you can catch those 80% less useful features earlier, and redirect your developers to the other 20%. Now this isn't to say that those 80% aren't important, but it does mean that you shouldn't put as much priority and emphasis on them.

He went over a few interesting techniques for breaking a product up into independent project regions. He also talked about how important it is to skin use-cases/examples into the simplest versions possible. Usually this involves reasonable (and sometimes unreasonable) sacrifices in usability. These simplifications let you skin stories into their simplest versions. The extra usability features can be added in later, once they're prioritized by the software users. They key is to get a full, working piece of software out to the users so they can tell you that you did it wrong. Although the software might be short on features, it covers the full breadth of the project. I thought this was one of the most useful things I learned that night. I definitely think we could have applied these techniques to j3wao, but I'm sure we will in the future.

In general, it was a great first Agile P2P. I'll be sure to be involved in more of these sorts of events in the future. In particular, uxWaterloo sounds quite interesting. I am really glad I discovered these community events. :)

Also, 528

Ignite Waterloo

I just got back from Ignite Waterloo, a set of 5-minute talks on everything and anything "geek culture"(whatever that means). The variety of topics was excellent. We went from Steampunk monsters, to problems in Africa, to Craniometry, to homelessness, to tequila. The breadth of topics was great. Here's a full list. If you didn't like a topic, a new one was just 5 minutes away. It was a fantastic event, and I strongly encourage that everyone go to the next one (probably June-ish).

Also, they had a live twitter wall and a marshmallow sculpting contest. Awesome.