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

Comparing IBM's Watson with Wolfram|Alpha

Here's an interesting comparison of Watson and Wolfram|Alpha. The article is by Stephen Wolfram, one of the designers of Wolfram|Alpha. It's interesting to see how they try to tackle the same problem in different ways.

Here's a great visual summary of the process:

source

Android vs iPhone development

I stumbled upon this article talking about the pros and cons of developing for the Android and iPhone platforms. It's an interesting read, especially if you've had some experience developing mobile apps. I agree with most of the points made in the article.

In the 2 months I've been working on j3wao, I've already encounter a bunch of the Android issues the article talks about. Probably the biggest complication we've hit so far is the huge disparity of device screen resolutions. Targeting all Android phones is a nightmare for this reason alone. Another major issue is the emulator. It takes something like 2-3 minutes to start up and load the home screen. Every operation on the phone is incredibly laggy, even basic things like doing the unlock slide. We might have a lot of issues testing our game on the emulator because of this issue.

Unfortunately, we are (realistically) stuck with Android-based development and testing for j3wao. While we plan to deploy to iOS devices, Android will probably be the primary target for development and testing. There's more financial commitment to developing for iPhone. At the very least, we need a $99 licence fee.  There's also the fact that we need Macs to develop and test on. This is a major inconvenience when we have 4 developers for this project. You get what you pay for, I guess.

An Insight Into Watson's Brain

I found a neat article briefly discussing how Watson derives solutions. A much more in-depth analysis can be found here. It's amazing to see so many different aspects of computer science come together to create something like Watson. Most, if not all, the techniques used by Watson have been around for years now, but Watson is probably one of the first to combine them all in such a powerful way. It probably helps that it runs on specialized (and expensive) IBM hardware. The impressive performance of Watson is a great milestone in artificial intelligence and computer science. It's a good time to be in CS. :P

Medical Applications of Watson

After last night's impressive performance from Watson, a lot of people are talking about future applications of a system like Watson. I am excited to see how it does today. Hopefully it will do even better this time around.

A particularly interesting application of an AI system like Watson is medical diagnosis. Watson could be used as a comprehensive medical dictionary, capable of matching a set of symptoms to a condition. This sort of "diagnosis suggestion" to physicians could prove to be very useful. It would ensure that every possible disease is checked against, and nothing is overlooked.

Of course, a huge problem would be information filtering. There are a lot of possible causes to a soar throat and a cough. I've mentioned a this a few times before now. Health care practitioners usually don't have time to do a comprehensive scan of everything that may or may not be relevant to a case. I've been told that most physicians prefer something like "history of cancer" over a huge record of medical history. I think one of the largest goals of technology in healthcare will be to deliver concise, valuable information to medical practitioners, while ensuring that nothing important is missed.

A system like Watson might also be used as a filtering system to alleviate this problem. The system could query for potential causes, and then filter them based on probability. Doctor's could then walk down the list, checking for the possible problems.  Of course, this system wouldn't be put to use every time someone goes to the doctor. It would be reserved for "harder" cases, where the doctor doesn't have an immediately obvious idea of how to proceed.

It'll be interesting to see how long before we see ramifications of Watson show up in the healthcare field. I, for one, am looking forward to it.

Functional Programming In Object Oriented Development

In first year, we learned about functional programming. We learned about the evils of mutation, and the power of stateless programming. Unfortunately, everyone abandoned functional programming the second they got the chance. They picked Java (or C++ (OR EVEN C!)) instead of Scheme because they were more comfortable with imperative programming.

The problem is that most functional languages don't have great support for industry-strength development. They don't let you quickly build GUIs, or have built in support for design patterns. Granted they don't need a lot of support for design patterns, since the language itself makes them obsolete. All this really means though, is that functional programming languages shouldn't be your base language for your application. It is still a good idea to have small functional modules, or even better, to just code with functional programming in mind when you write your imperative code.

I realize that imperative and functional are somewhat conflicting paradigms. One revolves around modifying state, and the other tries to avoid it as much as possible. Like most things, it's a balance. Not every object needs to be mutable, and not every function needs to be recursive.

Here's a few things that I have found useful in imperative programing.

Immutable Variable
It really helps to have variables that don't change their values after initialization. If you need to change a variable's value, you can make a new variable. This makes debugging much simpler, and it's easier to think about your code. However, this doesn't always make sense in imperative programming. If you are making a counter, this obviously doesn't apply, and making counters the "functional" way is unintuitive. On the other hand, if you are modifying a string in several ways, several immutable variables might make sense:



Code like this is much simpler to test, since you can easily see the progress of the transformation of your string.

Immutable Objects
It makes sense for some object to be immutable. This applies well to plain data objects, or objects that simply aggregate related information. Immutable objects are inheritable thread-safe and simpler to code. You don't need to worry about coding complicated methods like clone (in Java). However, if you make every object immutable, you end up with really awkward looking object oriented code. Again, it's a balance.



Use Recursion
Some objects are naturally recursive, so it makes sense that operations on them should be recursive. This makes the code very natural. However, you shouldn't use tail recursion in imperative programming. You are essentially writing an awkward for loop. In fact, some compilers will optimize tail recursion and for loops into the same thing.




Avoid side-effects
Functions that don't modify state are much simpler to think about. They also make multi-threading those functions much simpler, since you minimize the amount of ways to change values. This is a hard rule to follow gracefully in a paradigm that revolves around methods changing state. The key is that not every function needs to change state. You have to choose side-effect free methods carefully. Static functions are usually great candidate for this.


Referential Transparency
This is just a fancy word for a function that doesn't depend on anything other than it's parameters. If I call the function with the same parameters, I should get back the same result, regardless of the outside circumstances. Writing functions like this makes threading much simpler, since these functions don't depend on outside state. Functions like these are also very simple to test since they don't have any external dependencies.


These are just a few things to keep in mind when you are writing code in object oriented code. It'll make your imperative code much cleaner and simpler to code, test, and debug.

</somewhat productive>
<Watching Troll 2>

More Interview Questions!

For all you co-op kids, here's a nice list of interview questions. Hope this helps you get that dream job! :)

Smartphone Medical Devices

Check this out. A company called MobiUS released a very cool, and very portable, ultrasound system. The system is primarily comprised of the wand and a smartphone. Because both of these components are so small and portable, the entire system is very mobile and inexpensive to use. Further, because the device stores the data  in a phone, it makes sharing the data very easy.

I think it's really interesting to see all the new applications coming out of smartphones. I'd like to see what other innovations we might see from smartphones.

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.

More on GWT

I've been using GWT for over a month now at work. It really saves time when it comes to creating AJAX applications because it handles so much for you. For example, it can handle page transition and history very gracefully for you. It also has support for things like RPC and using JSON data.

However, if you are building an application that needs to be heavily styled, GWT might not be your best choice. First, the selection of GWT widgets are quite limited. Last time I checked, they only had 20ish standard widgets. Although there seem to be plenty of 3rd party widgets, I am unimpressed with their general quality and documentation. To make things worse, styling GWT widgets is a more complicated because not everything gets translated to native HTML tags. Some of the widgets are implemented as nested divs, and this certainly seems to make styling much harder. In general, the HTML output of GWT code is less clean than hand-coded HTML. At work, I had to take the style sheets made by the designer and try to apply them to the GWT-generated HTML and it was sort of a pain. I think part of the problem is that I'm not a web designer by any means. I had to basically (re)learn HTML and CSS. :/

In other news, course enrollment is tomorrow. I am currently pre-enrolled in CS 452: Real-time, but I don't know if I want to do it or not. The course load is ridiculous, but you learn a lot. If I do choose to take it, I would be able to take 4 courses that term thanks to Arts 304 this semester. Unfortunately, next semester in the only time I can take it for the rest of my academic career. :/

J3WAO Game

So I realize that I haven't talked about the actual game we want to create for J3WAO.

Our game is a music driven RPG. The player's attack are linked to music and interactive cues on the screen. The player needs to tap (or swipe!) the screen at the right time and place, based on the music. The attack mechanics are very much osu! inspired. We are also working on a storyline and a Final Fantasy Tactics style map.

We are planning to release to both iPhone and Android. We also have plans to release a desktop (web-based) version. We are using Adobe AIR to give us the flexibility to deploy to all these platforms with minimal effort. We get to use Adobe Flash and Actionscript 3 for development. These tools have great support for game design, so using this platform will probably save us a lot of development time.

Our first milestone release (of the three scheduled for the course) is next Thursday. Our goal is to have a simple proof of concept demo out by then. I'll try to post some screenshots of the game when it gets more presentable. :P

Pet Peeve #582: Bad Documentation

At work, I've been using GWT, and for the most part I've really enjoyed it. Occasionally though, I get frustrated by some things. For example AutoBean, a JSON-to-Java object parser for GWT, has almost no documentation. The Google Code wiki page is literal one of the only pieces of documentation out there, and it's quite bare. :/

Today I had to parse JSON lists using AutoBean. Here is the only relevant statement I was able to find:

List and Set properties are encoded as JSON lists. For example, a List<Person> would be encoded as:

[ { "name" : "John Doe" } , { "name" : "Jim Smith" }]

No information on how to go the other. Not cool. I had to do a lot of experimenting to find out that AutoBean only accepts something like this right now:

{ people=[ { "name" : "John Doe" } , { "name" : "Jim Smith" }]}

Hopefully this will be improved for the next release.

Also, there were very few code examples online. Open source software can be really cool in that they provide a lot of really useful tools, but their lack of support is quite frustrating. This is not to say that all open source software has horrible documentation, but in my experience, it is usually worse than the Proprietary equivalents. Just take a look at MSDN vs Oracle's Java documentation. Thankfully, a co-worker helped me find a workaround that he had used in a different project.

Anyway, time to learn everything to there is to learn about Flash/AIR/ActionScript 3. Our J3WAO sprint ends tomorrow, and we still have a lot (all) of our development left to do. :P