C++0x: Dead Horse With Jetpacks

So you may have heard that the newest version of C++ (C++0x) has been finalized. I finally took a look over most of the changes they made. You can find a nice, comprehensive list here. God dammit. I can honestly say that I've never seen a language with syntax this ugly. It's much more complicated than it has to be, mostly because it has to retain backwards compatibility. They took an already complex language and added even more complexity to it. I think they should have just let C++ die, and waited for C# to take over. This standard is trying to desperately revive a dieing language by adding random features that other languages have had for years (decades in some cases!). It's like adding jetpacks to a dead horse and saying 'Eh. That should work'.

Should you use C++0x? Well, if for some reason you have to write C++, you should use the features introduced in 0x. Otherwise, I don't see why someone would choose C++0x over something like C# or Java. If you are writing something very low-level, object oriented C++ is the wrong language, and if you're writing almost anything higher level, C# and Java are much better choices. The only possible market for C++ I've ever seen is game design, where the language needs objects, as well as low level access for speed.

So, what do you think of C++0x?

Why Linux Won't Be A Popular OS Any Time Soon

Yesterday, I went out with a few friends for some billiards. Of course, since we're all nerds, we got to talking about open source software for 3 hours at Tim Hortons. This happens pretty much every time I'm in Toronto and hang out with these people. I love it. We play pool, drink coffee, and talk about technology. I enjoy having a group of friends that I can have these conversations with. :)

Anyway, yesterday we touched on the topic of Linux becoming a popular operating system for the masses. One friend thought that Linux was on it's way to become a popular OS for the average computer user. I disagree. Linux still has the image of an operating system made for experienced computer users. Until  they break this image, they will never be accessible to the average user. For example, look at troubleshooting in Linux. Google any common problem you might have in Linux, and the first page of results will all be cryptic command line tricks to get something to work. The language used is often way over the head of a lot of computer users. The average computer user will be intimidated by this. Until Linux changes this culture of just encouraging people to use command line to solve any problem, they're never going to become popular with average users.

So is this command line culture ever going to change? Maybe. But not anytime soon. A lot of members in the Linux community probably don't consider making GUIs on top of a few simple commands. Even though this is exactly what it would take to get people to use Linux more. I would argue that this community is not thinking about usability as much as they should be.

What do you guys think? Do you see this as a problem for Linux? Do you see it being solve any time soon?

Should UI be required for a CS degree?

Yesterday, I went to a uxWaterloo event. There were a bunch of 7 minute talks on various topics in usability. One of the topics that caught my interest was the question if UI should be a required course for CS degrees?

Based on the discussion that followed the talk, the majority of people seemed to like the idea of including UI courses in CS degrees as a required component. After all, a lot of people with CS degrees go into the workforce as software developers working on user interfaces. However, CS isn't really about developing usable software. It's not really about developing software period. CS is more about the theoretical study of mathematical computation and information processing.

Software engineering is the program about developing software. I think that UI should definitely be a core part of a software engineering degree, but I don't think it's a good idea to included it as a core course in CS. CS is already this murky field that's half theoretical and half practical. I think a good solution is to make the theoretical courses required for CS degrees, but offer a wide variety of optional, practical courses. UI, of course, should be in that optional list of courses. Promoting these optional courses is also very important aspect of getting people more interested in UX.

So what do you guys think? Should UI be a core component of CS degrees?

Testing with Real Data

It's really important to test your applications with real data. I learned this when I worked in QA for Ramsoft Inc. I found it much easier to spot problems with the product when there were real data values in the application. Certainly you don't need real values to spot glaring errors like segfaults or something, but to find the more subtle bugs, having real data really helps. Some usability problems become very transparent when you use real data instead of "ksodaguhkudhgau".

When you use real data, you put yourself in your user's shoes. Having this perspective on the application really helps create a better application. You can solve a lot of usability issues by using real data during development and testing, instead of discovering them when you put the application in front of your users for the first time.

To this end, when I do user interface development at Karos Health, I try to use real data as much as possible. This helps me find ways to improve the UI to make it more usable, and helps me understand the high level purpose of the application better. It also makes for much better demos at the end of our sprints. :)

<3 Software Engineering (and Mockito)

At work today, I took a lot of time to write unit tests properly. There was a lot of refactoring, dependency injection, and mocking. I was using Mockito as a mocking framework, and I am very impressed so far. The syntax is simply beautiful. Simple, to-the-point, elegant. Check it out:

Wow. This is so clean! Look at line 7. It reads like an English sentence. Or Ruby. Go figure. Certainly not like most noisy Java code.

Today I remembered why I really love software development. It's so cool to see such complicated modules of code working together in such elegant ways. Things like dependency injection and programming to modular interfaces all come together to let you do some really powerful things, like unit testing. I'm so impressed that you can take any random component in a huge, complex system, and be able to run it in isolation. The amount of software engineering it takes to get that to work in a huge system is quite impressive. It reminds me why I'm so fascinated by software engineering.

Functional and Object Oriented Programming

In the past, I've talked about integrating functional and object oriented programming. I still feel like that's a great way to produce clean code.

This article addresses a few more aspect of functional and object oriented programing, including Bottom up vs Top down design.

Object Oriented programming often encourages thinking about code in a top down way. On the other hand, functional programs tend to be bottom up. I've found this to be pretty accurate in the past when I work with both paradigms.

One particularly interesting point made in the article is about reusability. Specifically, the article claims that bottom up code is inherently more generic because they are built before their exact uses are explicitly planned and encoded. I've never really thought about it like that, but it makes sense. In general, functional languages provide you with a lot of resources to create cleaner, more reusable code. First-class functions are probably the biggest convince they offer for creating clean code. Of course, reusability isn't always the best goal anyway. Reusable code just happens to also have a lot of other very desirable properties. 

J3WAO update

It's been a while since I talked about our progress with J3WAO. The biggest update is that we changed the scope of the project. Originally, we were planning on making an RPG with a music-driven battle engine. Instead, we are making more of an action game with the same battle engine. Instead of advancing the story through RPG elements like map exploration, the story will be advanced more like a fighting game. Specifically, the story will be developed through cut scenes or dialog that is between planned battles.

The reason we decided on this change was to because of time constraints. Our team is more busy than we originally thought, so we don't have time to implement everything that we wanted. We changed the project so that we could release a complete, polished, and content-filled game for the end of the course.

However, we are still planning to create an RPG version of the game. We will have two complete games to release to market when we are done. That should be very cool. :)

As for progress, our team is mostly done the battle engine. After we get a few more features ironed out, we can move onto our game engine that will transition between stories and battles. Once that's done, we will focus on content generation, testing, and deployment. It should be an exciting few weeks. There's only 4 more weeks until the course is done, so we're working hard to get this thing out. :)

What Test Driven Development Is Really About

This article talks about how Test-Driven Development (TDD) isn't really about testing; it's about design.

The goal of TDD is to design the structure of the code before you start programing. Getting better test coverage is really just a side-effect of that. Writing the tests is more of a design activity than a testing activity. It helps you create code that is easier to work with, because you are constantly thinking about how to test your code. And of course, testable code often has other very desirable properties like loose coupling and modular components.

This new perspective on TDD makes a lot more sense to me. It makes more sense to me that TDD is about design, and up-front thinking about code, instead of following rules on how and when you write your tests and code.

Swarming!

Our project manager at Karos Health shared a link with us the other day about Swarming.

This is the first time I've heard of this technique and it sounds quite interesting. The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done.

I also think having many developers focused on a single story encourages collaboration and teamwork. It forces everyone to work together very closely, and this probably leads to getting the story done faster.

Of course, the story in question needs to be big enough to allow multiple developers to work on it together without stepping on each other's toes. If our J3WAO stories weren't so small, I think it would be interesting to try it there.

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

Good Software Architects

Do you have to be a good software developer to be a good software architect?

This is an interesting question that came up in a random conversation with a friend. He was of the opinion that a person can be great at high level design, but be bad at actually programming. He claimed that the two activities are far enough apart that someone could be good at one and poor at the other. I'm not sure that I agree.

Part of high level design is thinking about how the implementation will actually work. A lot of the time, something looks great on paper, but it's a major pain to implement. Sometimes it's not even worth the effort to implement. A good architect should be able to balance these factors, and being a good programmer helps identify these potentially troublesome design choices.

Further, to be a good software designer, you need to a lot of experience working with growing applications. You need to know how each design decision effects the project as a whole, as well as the developers working on the project. I think the best way to get this experience is from working as a developer. That way, you get to see the good (and bad) ramifications of design decisions first hand.

Being a good developer also gives the architect a better view of any software project. They know how every detail might work, regardless of whether it's a high level design choice, or a how that design choice might be implemented. This gives the architect a more complete view of the project, and allows them to make a more informed decision.

I am very curious about what you guys think. Comment to let me know what "camp" you're in and why. I'd love to hear everyone's take on this.