Roughly 500 routes, 8700 stops, 126000 trips and 3.4 million timepoints at those stops. Not a whopping amount of data, but enough to start having some fun. My initial plan was just to be able to plot the stops for a given route onto google maps. That’s done in it’s ugly glory at my stopfinder. If you want to search for a 1 or 2 digit route, put in the leading 0’s. Sorry, haven’t done that yet.

My next steps are going to be to publish a number of primitive operations on the data with results in JSON format. Things like ‘closest stop to lat,lon’, ‘how to get from stop x to stop y’, and other similar sorts of things. The idea being that if I can build up a suitable library of common operations on the dataset, any future ideas that do come to mind should be relatively easy to implement.

That and if anyone does want to do some data mining, well, this is an option. I’ll post any updates, formats and that sort of thing on this site as I work through it. In general, the services will be pretty much simply URL based and will return raw JSON. Nothing special, but fairly easy to parse and work with. I have a relatively irrational dislike of XML which I will probably get over at some point, but it will take someone making a very good argument.

So it is, but actually stating that, or anything along those lines? Way to kill the team, boss! (See Peopleware)

That said, quality assurance, quality control, QA, call it what you want, but it’s one of the more misunderstood aspects to software development. Oh sure, everyone knows that they need to do more QA or better QA, but lip service is about all that is ever paid towards it. I am notably not including in my ‘everyone’ those who feel that QA can be completely automated. You guys are wrong and I’m going to leave it at that. You also may think you don’t need to do it, see this article for some classic arguments against that fallacy.

I’m not going to go into depth about QA, how to do it, best practices or anything along those lines as I’m fairly unqualified. That said, I’m not really qualified to talk about anything, but that doesn’t really stop me.

QA is a processes, not a task

This particular fail case is something I’ve seen in multiple organizations now. The most obvious symptom of this is when management has decreed that there is a block of a few hours set aside to ‘do QA’ on an application with a few hundred known use cases. Another obvious indicator is when other employees are volunteered to do a few hours of QA on top of their normal job. Think you’re going to get good results from that?

The root cause of this failure is simply not understanding how QA works, so let’s walk through it a bit. In a very broad sense, the general list of tasks for QA is something like this:

1. Go through the basic cases

2. Go through the corner cases

3. Go through obscure, known failure cases

4. Exploratory testing

5. Automating 1, 2 and 3.

So, how does this fit into a day of work? Let’s find out:

First off, we’re going to go through the basic use cases for the application. Then, there is a pile of corner cases that are pretty valid that need to be checked out. Then it’s time to check all the really obscure, but horribly embarrassing failures that have been seen before. From there we can finally…What? You changed the code? Okay, first off, we’re going to go through the basic use cases for the application…

Interruption here! “Silly tester,” says the savvy developer, “You only need to re-test the parts of the system that were changed.” Nice theory, but wrong in many, many ways. Simply put, if this was the case, testing outside of developers would never be needed. That generally goes well.

Back to the task at hand, do the basic cases, do the corner caWHAT? Changed again? Basic cases…

The real job of QA starts at step 4, which we haven’t even seen yet. Exploratory testing is finding the embarrassing defects before they get out into the wild. A good tester at this phase is going to break your application in ways you haven’t even dreamed of. In ways that only 0.1% of your users would ever try to do. Of course, if 0.1% of your users do it, and you get 10k uniques per day? That’s 10 people per day that are going to hit this embarrassing bug that how could you possible let into the wild and I’m taking my business elsewhere right now as I obviously cannot trust you with my data. And if one of those has a blog? Heh. Have fun with that.

So the epic fail with having 16 hours scheduled in to test your quarter million lines of code application? If you’ve got bug fixing going on at the same time, any of your competent testers will never get past step 1. Any testers that listen to the savvy developer, or worse, are the savvy developer will miss basic cases and you deploy with fundamental breaks.

The purpose of QA is not to have someone say, “Wonderful developer, your application is perfect!” If I hear that from a tester, I assume the person isn’t doing their job very well. QA should hurt your feelings. Assumptions you made should be laid bare and justified or thrown out if incorrect. This is often the last line of defense before your customers see your application, take it seriously.

So there was lots of refreshing of information, which was notably taking up my brain time which meant to less time learning wholly new things. This is okay, but one of the best things about software development is the constant learning. So when a company mentioned that they were using Hadoop and HBase, this was instantly exciting to me as it gave me a perfectly good reason to go and research some new technologies.

If you haven’t heard of these two projects, and unless you are specifically working with them, you probably haven’t, Hadoop and HBase are free software implementations of two systems designed by Google, MapReduce and BigTable respectively. MapReduce is a framework developed by Google to facilitate processing and working with large datasets across a distributed network. BigTable is essentially a way to store structured data across a distributed network, though it is important to note that this structured in terms of nested hashes, not in a traditional relational manner.

Google had a few motivations for building something like this. They regularly worked with gigantic datasets, their search index itself, search logs and Google Maps tilesets as a few examples. Analyzing these datasets took massive CPU resources and a distributed approach was more or less deemed the only practical way to actually compute solutions. MapReduce takes the classic divide and conquer approach to solving a problem. The problem space is split up and doled out to dozens, hundreds or thousands of computers. This is the map phase. Results from each piece of the calculation is then returned to the master computer which then reduces the results down into some sort of final output.

This approach has been used for solving all sorts of distributed problems, but MapReduce was unique in that it was a framework, usable for a variety of tasks. The hard parts of managing a distributed network for a single calculation are often just that, the management tasks. Deciding which servers get which chunks of data depending on where they are in the network. Deciding if a server has crashed, or if it’s just slow. How and what, if any, data do you duplicate across multiple nodes to guarantee that you get an answer. These are all concerns that must be addressed when creating a distributed application.

What Google did with MapReduce was abstract away the management tasks so their developers could focus on actually writing the algorithms to solve the problems. Hadoop is a Java version of MapReduce. But I digress.

What was really nice was that in the midst of this review and stress, as looking for meaningful employment is not without some concerns, was an opportunity to read a couple of new papers and learn some new things. So I promptly went and wrote a distributed program to calculate how many lines each character in the collected works of Shakespeare spoke. This was not something that required much computer horsepower, but it was pretty cool to run the thing on two computers and get chunks distributed to each of them.

So that went over well. I am going to post this now as I have been sitting on this for a while and not finishing it up. I need to lower my standards somewhat as, to paraphrase Joel and Jeff, I only have one reader anyway.

It was directly due to the words of a couple of well respected bloggers that I started this one. There are multiple reasons. By writing, you exercise the communication part of the brain, which is always good. By putting up a public blog, it becomes easier to control your own Internet presence. As long as your writing is even passable, it is good marketing for yourself. These were just a few of the points that were made. I bought into it and am now going on a couple of months of roughly weekly posts. I believe I can keep this up rather easily.

So, one mission accomplished.

On more than one occasion, one of these people who are well respected in the software development field will mention something about a compiler. Specifically, that every serious programmer should write one at some point in time. This makes sense as a compiler tends to be one of those bits of software that does a good job of covering pretty much everything that a programmer needs to do somewhat regularly. Lots of string manipulation, lots of recursion, lots of knowledge about how a computer actually works, memory management, the list goes on.

I have not yet written a compiler. It is something that I have wanted to do more than once, but never actually sat down and started working on it. I’ve seen enough mentions in passing recently that I feel it is time for me to complete this particular rite of passage and actually write a compiler. I am capable of it, but I needed the push down the right path to do it.

So it is not going to be a huge project and I’m not going to sink huge amounts of time into it, but I do have goals for it that should be completed by the end of 2009. I need to define my own language, it should have ifs and whiles, it should evaluate mathmatical expressions correctly. I think I will compile to JVM compatible byte code, though I have not decided on that yet either. That would theoretically allow me to use Java libraries as well, which is appealing. It’s not going to be object oriented, mainly as this is a learning experience and I don’t want to bite off more than I can chew so to speak.

I’m leaning towards Ruby for the project, but am stronger with Java which will make some things significantly easier. I will likely make the final decision once I’ve read some of the Dragon book and know more about what I am getting into. My intention is to write it all at this point. I don’t think I will use a parser generator or anything like that, simply as the point of this is to learn how to write a parser/lexer/etc.

So that’s the plan for 2009, dedicate a couple of hours a week to this project and hopefully be able to run some of my own code in my own language by the end of the year. Who knows if that’s reasonable, but it should be… illuminating.

During one of the interviews a comment was made in passing about programmers not wanting to talk to clients. This is a popular topic for developers to joke about, but I had always treated that as a joke. When it came down to the business of doing business, well, talking to your clients is just to be expected. Ultimately, they are the reason you have a job, so there is something very serious to be said for treating your clients with respect.

This particular ramble is going to go down a couple of paths, I’m going for breadth more than depth here.

Generally a software developer is writing code for one of two different reasons. You are writing software for a new product that may or may not have clients yet, you may be trying to carve a niche into an existing market or creating a new one. The second and by far the most common reason is that you are contracted to write software that accomplishes some task for another person/organization/demographic/etc.

So what does that make our job as developers? Our clients or employers have problems that they have decided for whatever reason are best solved by computers. We are to analyze that problem and develop a solution. Hopefully that solution makes our clients more money or saves them money by making existing processes more efficient. If the post-mortem shows that the cost/benefit ratio is less than 1, then we have failed. It really is that simple.

Solving a client’s problem is our job. One of the aspects that makes software development so much fun is that many times our client does not know exactly what they want. This may be a source of entertainment for us, but is a very important thing to keep in mind. The world of programming is one of absolutes, the computer does exactly what we tell it to in a nice and ordered fashion. (Defects being the times when we tell the computer to do the wrong thing) The real world is much less black and white. What this means is that we have to listen to our clients and understand what they are trying to accomplish. If the request is vague, we have to figure this out by asking the proper questions to build a better picture of their business.

This is challenging.

Worse, they may know exactly what they want, but are wrong. I have personally been asked to implement things with very little more than a vague bit of hand waving and comments to the effect of “We think having something that does x would be nice.” In this particular case, x was fairly obviously, to a developer of the system who had detailed usage statistics, not what our users needed. They actually needed y. Through some discussion with our clients, our team was able to make the case that x would only help less than 1% of our users, and a particular subset of users who did not and would not spend any money. That probably helped our case somewhat. We ended up implementing a modified y and our customer service requests for a certain class of problem dropped significantly.

What was interesting to me from a personal standpoint was that the same people who were arguing to just implement x were the same ones who did not want to talk to the client. Now, I should clarify, I don’t mean, the grudging, “Oh no, small talk and meetings with people I don’t know”, the typical introvert response where you know that you will come out of the meeting drained, though hopefully with the problem solved. In this case I mean attempting to make the case that it was not our job to talk to the client to figure out what they needed.

This did not sit well with me. There is a reason that the principles of the Agile Manifesto have several points which specifically reference and talk about dealing with the customer. These points all touch on dealing with the customer with respect and understanding as they are the experts in their own business. We are experts in software development.

As software developers, our job is to learn from our clients to build systems that improve their business. To do that, we will always need to interact with our clients to determine their needs and meet them.

The difficulty is that there are only so many programming books that are truly classics. While I appreciate and enjoy learning from well written Hibernate or book on the Google Web Toolkit, ultimately, any software book that starts to discuss a specific framework will quickly become obsolete. As one of my personal definitions of classic is a book that does not grow old with time, this means that a huge percentage of mass market “Learn how to gidazzle with widget fooxily” types of books will never reach the classic status.

Unfortunately, it seems that the dominant type of programming book that is on the shelf in your local bookstore are exactly the ones that will be out of date in a couple of years. This makes me somewhat sad as if the market is for books that quickly go obsolete, the number of people that will write books that go on to be classics will be smaller simply on a basis of supply and demand. I’m not sure where this leaves us. I like buying technology of the month books as well, so I help this. All in all, it’s likely not a problem I suppose. I guess I just wish I could actually find Peopleware or the Mythical Man Month in print on a shelf somewhere.

So now I reach the real crux of the matter. If you are reading this, then you probably read other blogs by various guys in the software industry and they already have pretty much written about the books that you absolutely should read. More, most of you have probably read some of the books that Joel or Jeff have suggested in the past. So I’d simply be duplicating content listing the exact same classic books and suggesting that a serious programmer should read them.

So this has all been a debate as to whether or not to do that. You see, I actually enjoy reading reading lists, especially if there is a little blurb about why the book is good. Every once in a while a wholly new book turns up and I will add it to my ‘to read’ list and I am the wiser for it. Still, I think I can stand up to it and avoid actually creating a reading list of some form.

That about wraps it up for today, this was more of a random ramble than anything else. Back to actual geek topics soon enough.

HTML had some limitations though, it was kind of verbose and you had to mix up your content, paragraphs and such, with code that was used to show how the thing should be laid out and look. At more or less the same time, there were two new pushes to make HTML better. Javascript (1995) was developed to allow a web site designer to make things change on a page. No longer would a web page be a simple static document like a magazine or newspaper article. Cascading Style Sheets (CSS – 1995-1996ish) was created to help a web designer keep the content, the article, online store, etc. distinct and in a different place from the stuff that was responsible for how that content actually looked on the page.

And this was Awesome, except, it wasn’t. At the time that these developments were happening, the First Browser War was underway. Netscape put some Javascript and CSS stuff into their browser. Microsoft put different things into theirs. Bit players in the browser wars did other things. The end result was that if you wanted to make a sufficiently sophisticated web page, you had to create two or three versions of the thing so that it actually worked in multiple browsers. Now, for a long while, this did not actually matter as Internet Explorer 6 held so much market share that you could target IE6 only and get away with it.

That is no longer the case. Arguably, it was never the case, but there were lots of so called ‘web developers’ who happily wrote sites that worked in IE6 and IE6 alone. There are several major browsers now. More importantly, there are several major devices now. Blackberries, cell phones and game consoles all have limited support for browsing the web in various forms. It’s probably a good idea to try to write your web code in such a way it works in as many platforms as possible. More specifically, at least the major platforms that your clients are using.

Approaches

Inevitably, however, some of the fancy dynamic content, crazy layouts or Javascript dancing puppies will not work on some platform that at least some of your customers are using. There are a couple of different strategies for dealing with this scenario: Progressive Enhancement and Graceful Degradation. Effectively, the end result of either of these strategies is the same thing. A website that functions properly under just about every browser platform. There is overlap between the two strategies, in that you can safely say a website built via a progressive enhancement strategy will degrade gracefully. That said, there is definitely a difference in the development process when building a web application in either of these manners.

Having worked on projects that focused on graceful degradation, I can offer my opinion that it is a route fraught with problems. My gut feeling is that if you are going this route, you’re almost better off writing off customers who don’t have your minimum supported browser.

Progressive Enhancement and HIJAX

I’m mostly going to talk about progressive enhancement now as my current project has gone that route. I mainly went that way as I was concerned with the smell of the code that I had written or worked on in the past that went the other way around. Taking a full featured, beautiful Web 2.0 application and trying to hack in static HTML support was difficult and led to some fragile functionality in places. Progressive enhancement seemed to solve that problem in that you started with a functional, solid HTML version and then began to add the flashy enhancements.

Google for HIJAX and read some of the blog posts you find, all are pretty short and give you an overview of the approach I am making with this particular application. There isn’t really a definitive definition of HIJAX, suffice it to say, the point of the thing is what I outlined above. Normal, old fashioned site first, then start writing the flash. The basic philosophy is “Plan for AJAX from the start. Implement AJAX at the end.”

Of course, there is no silver bullet.

While I truly do like the development process that follows with HIJAX, I cannot help but feel I have traded one type of code smell with another. Well, in this case, it isn’t really code smell, it’s more of a project management smell. The single biggest problem I have with the simple HIJAX philosophy is how simply it discounts the nature of web applications.

Implement AJAX at the end.

This is where it all falls apart. Anyone who has built web application that goes beyond the trivial knows that there is no end. Paul Graham talks about the advantages to web development in The Other Road Ahead. He has an entire section dedicated to releases and notes that in a web application, you really don’t have releases. You have features that you deploy one or two at a time.

So if there is no end, implementing AJAX at the end isn’t really possible. So the HIJAX philosophy migrates more into a “Plan for AJAX from the start. Implement AJAX in chunks as you go along.” This is notably still different from “Implement AJAX from the start”, but must be pointed out. The majority of articles and essays on this topic that I have read thus far do not take a high level perspective. They deal with specific implementation issues and provide an outline that works at the feature level. The naive philosophy will not work when applied to an entire project.

This is not to say that it is a lost cause and we should get back to writing rich applications that only work in specific versions of Firefox. Progressive enhancement is the way to go for a general purpose application on the Internet where you do not want to drive away any customers. HIJAX, on the other hand, is a nice buzzword for a simplified philosophy that I think will die out quickly as it becomes apparant that it is just a bit too simple.

You know, the ones that we developers have all the time. “I really want something that does X, but everything currently out there kind of sucks.” Though, recently I’ve found most of the things that I want are already out there, but they are a pain to use. I’m not sure where I read it, most likely either Steve Yegge or Joel Spolsky, but the general gist of the thing was that you could probably make a decent living taking some decent products out there and simplifying them down so that any grandmother could use them.

At about this time of year, I start to get questions about what sorts of things I would be interested in for Christmas. I generally respond with blank stares as I really can’t come up with much that I need. That said, throughout the year, I will occasionally stumble across something that might be fun or practical, but I can’t really justify purchasing it myself. What I needed was a way to list those things somehow and let my family see it online.

I took a crack at doing a wishlist a couple of years ago as a trial Ruby on Rails project, but I was pretty busy with other things at the time and while it was technically functional, it wasn’t really any easier than what was already out there. This time around, I took a look at some other wishlists on the market and while a few were good, a few were okay, none really satisfied me. This is probably due to the fact that I had been itching for a new programming project for a bit. Anyhow, I took a look at what the other sites offered and started coding. I have just put a closed beta onto a live server for friends and family and should be ready for a wider audience shortly.

Currently it’s good old fashioned HTML, no rich Javascript features or any fancy AJAX yet. That’s coming, but my goal is to make the thing work well with a simple UI, then enhance it slowly. My past couple of projects focused on building a rich web user interface first, which was followed by a half hearted attempt to bolt on a simpler version for browsers that do not have full Javascript support. This time, I am taking the opposite approach, to make a user interface that can run on any browser under the sun, then start adding features to make it more dynamic. Is this a good approach? Possibly, possibly not but I am going to go with it this time around. The only way to really learn if a strategy is a good one is to attempt to use it.

So, this is a Ruby on Rails project. I am trying to do things the Rails way as much as possible. I am using an Apache web server to serve static content and load balance between what is currently a cluster of three mongrel servers. This is massive overkill, but was fun to setup. Deployment is done with capistrano and I am developing in Netbeans, which didn’t crash as much as Aptana RadRails, so I’m using it. Netbeans is a bit uglier, but what can you do… Naturally, everything is done in Linux. Subversion for source code and I’m trying out Mantis for bug tracking and such. All in all, configuration overhead probably ate up about two days learning everything and bashing my head against various walls.

Rails has been great to learn so far. I’m only getting faster at adding new features and cranking out more appropriate testing scenarios, which is good. Not only that, but I can see a lot of things that will improve my Java coding abilities as well. I suppose that’s why side projects are generally encouraged…

I took a stab at making a Ruby on Rails application a couple of years ago and when the start-up fell apart, I felt that I should use my now existing free time to give it another shot. The technology seemed fairly interesting and while my first crack ended up being relegated to the dust bin of my back up hard drive, it made me want to learn more about the language and framework. The project I have been working on for the past couple of weeks will likely get launched to family and friends in the next week or so and I’ll likely open it up to the public assuming there aren’t any real problems.

One thing that I discovered with Ruby on Rails the first time around is that the framework seemed almost sinister in it’s ability to detect a Java programmer. You’d go through, doing things, never quite sure what you have to write and what the framework does for you. Eventually, you’d step on metaphorical toes of Rails and things would silently stop working. Even worse, you’d get an exception or error from deep in the framework’s stack. It was as if there was some special code in place to detect common patterns from curious Java developers and would blow up in our faces. Probably not, but that’s what it felt like.

I picked up Rails Recipes a couple of weeks ago now and am very glad I did. The book is laid out in a fairly similar manner to the Gang of Four’s Design Patterns, in that it is really a collection of fairly unrelated strategies to conquer various problems. There are sections on how to improve your Rails testing, how to better use the built in Rails support for the Prototype and script.aculo.us Javascript libraries, common ActiveRecord (Rails data abstraction layer for those who haven’t used rails), etc.

The book is well written and to the point. I read through most of the recipes which were relevant to me in less than a day. What was really nice was that there were several how to guides for things which appear in many real projects, but are a bit more sophisticated than what usually appears in the Rails tutorials found in the wild on the Internet. Things like self referential many to many relationships are common enough that you have to know that there is support for it built into Rails, but exactly which incantations are required to correctly set it up are not exactly clear.

Rails Recipes is excellent for things like this. Tasks that are common and are a part of the framework, but are just complicated enough that the basic tutorials do not cover them. I had found that there was a large gap in documentation online between the Rails newbie guides and Rails expert solutions. This book fills that gap nicely.

Many books specific to languages and frameworks, once you have advanced beyond a certain proficiency level they cease to be useful. Rails Recipes is not immune to this and while I am not there yet, I can see the day when I look at the topics covered and think, “How quaint.” That said, though, I definitely feel that this book will help me get to that point more quickly and efficiently than I would have done alone or with the help of the documentation that is currently published on the Internet.

For me, this was definitely worth the investment. If you are a Rails guru, maybe skim it in a bookstore first before buying, but if you are just getting over the rookie phase and looking for the next logical step to take to improve your abilities, this is a pretty good book to go with.

I first encountered Java way back in 1998. This was effectively my first programming language, though I had done some C++ in high school. That wasn’t formally, mostly self taught and pretty much purely due to laziness. At one of the computer shows in Vancouver, (which might have been Comdex, did that show travel around?) I talked my father into buying me a C++ compiler and toolchain. It was definitely Borland, I’m fairly certain it was one of the Turbo C++ packages, though I have no idea which version now. Regardless, my main goals were to ease my physics and math homework by writing programs to do various tedious calculations for me. That was more or less a success, I still recall the joy at punching 3 numbers in and getting the solutions to the quadratic equation back. I learned about loops, variables and if statements, but nothing else really. But I digress.

At Carleton University, the first programming course I took was in Java, at this point in time, we’re talking Java 1.1 for the most part, the entire API was a couple of hundred classes at most. Supposedly it was kind of exciting because it was object oriented, but that was way beyond me for at least a semester. Mostly what I recall from my entrance to the world of programming was my epic battles with the compiler. I hated javac. There was perfectly valid… things in my file, at least as far I could tell, but javac would tell me that in no uncertain terms that I could not go so far as to call that text ‘code’. Eventually, the program compiled and joy was felt throughout the lands. Immediately thereafter, I would run the program, which would crash with a NullPointerException or some other fun error case. This was before the time of decent debuggers, at least to a novice programmer, so with a liberal smattering of System.out.printlns, eventually I could figure out where I had a mistake. Then change the code, fight with the compiler and the scenario would repeat itself until I could run the test cases provided in the assignment.

All in all, though, Java in those early days was a pretty simple language. You would make an array, do stuff with it and be happy about it. Or, once you started to grok how this object oriented stuff worked, you’d make a Vector and stuff things inside of it and you would never worry about resizing the array again. I mean, there wasn’t much to the language, check out the 1.1.1 API I just googled for. There were a couple of weird features for a novice to see, anonymous inner classes are a great example, it took me years to really understand how to effectively use those things.

Java 1.2 was introduced in December of my first year and included a number of things, the only ones that actually mattered to me as a fledgling programmer was Swing and the Collections library. Swing because the winter term had a Java graphical user interface (GUI) course and the collections library because I could now cheat and use LinkedList instead of always having to write my own for each assignment. Maybe it wasn’t every assignment, it just seemed that way, still.

Java 1.3 did not really add anything of use to me and stayed out of my awareness. Java 1.4 added a few more things and I wrote a fair bit of code with that version. Still though, Java was still the same old Java as I had used back when I started with it. There were new libraries, and that was nice, Java was growing with me as I needed to do more with it. There wasn’t any real new syntax that had to be learned, if you hadn’t seen regular expressions before, it was a bit of a shock to see Perlish things in Java 1.4 but for those of us who had used them, it was nice to have the power of regular expressions in Java.

By this time I was working in the industry, specifically on a rather interesting Java application that was officially using 1.3 Java when I first showed up on the scene, 1.4 shortly after I started writing code for it. I should  note that I mean interesting in terms of the curse, “May you live in interesting times”. Not as in, “That book is great, some really interesting points.” The system was the definitive legacy but business critical application, so arbitrarily going to a new Java version wasn’t going to happen until the powers that be had given it the official green light. At the time I was happily drinking the generics kool-aid, helped in no small part by the .NET team at the company who was gushing about how much the .NET generics implementation had helped them. I pushed for the migration and eventually we had migrated to a 1.5 JVM and all was good.

I learned the new syntax for the generics and for a while it was great, but a few things were beginning to bug me. In the entire time I had worked at this company, I hadn’t actually seen a ClassCastException in the wild. This appeared to be the main thing that the generics were attempting to fix. The syntax was a bit clumsy and fairly verbose, especially if you had descriptive class names. Making a generic class was an exercise in pain. Enough so that after one serious attempt, I nixed it in favour of a single purpose class that could only take instances of a given interface. Most grievous in my mind was that after going through all of this anguish to get a generic class, as soon as you hit run time, you could not use reflection to actually figure out what *should* be in the container. I remember being shocked when I found this out and needing a coffee break to reassess.

From what I could tell, all of this extra syntax was being entirely tossed out before run time, which meant all that extra typing and ’safety’ was a merely a compile time check. One of the first lessons learned in programming was that just because something compiles does not mean it works. So while getting a bit of extra information at compile time is nice, I couldn’t help but think the benefits of the check was not worth the cost of the extra time spent typing and managing the syntax. (Side note, no, it’s not ‘just typing’, it is the most fundamental skill a programmer needs to have and should be taken very seriously. Arguments here and here.)

Regardless, I soldiered on and slowly encountered other 1.5 enhancements that made Java more complex. Annotations, which through a new syntax would allow you to add some extra meaning to a method, class or variable. Enumerations, which I do love using when the previous option was lists of static final integers or strings. That however, was done with a new keyword, ‘enum’, which by some entertaining coincidence was the exact variable name used throughout our codebase for Enumerations. (Enumeration enum = hash.keys(); Eventually I will write more on code quality in that entertaining project.) Never mind the fact that now you have to talk about Enumerations or enumerations, which is always entertaining. Then there is the varargs syntax, which just feels like a solution in search of a very specific problem. Seriously, I mean, have you ever needed this? Then there is autoboxing, a nice feature, but blurs the lines between objects and the Java primitive types, which can lead to a whole new way for developers to misunderstand what a block of code is doing.

I no longer feel that Java is a good language for a new developer to start programming in. It has it’s advantages, but those are almost exclusively in the domain of large ‘enterprise’ systems now. Some of the changes appear to have been to keep maintenance costs down and to mitigate the damage a low quality programmer can do. Some of the changes appear to have been good ideas, but they were done at the cost of making the syntax more complex and complexity is the enemy of software development.