Bikes and Code

I’m back. Took a bit of a break over the Christmas season and enjoyed not working on software, programming and business for a few days. I did have a few interviews, which is always stressful, so I tried a bit harder to actually enjoy the downtime that I did have.

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.

It seems that everyone who writes about programming topics in a blog format eventually writes an article on what books they feel are important to read to improve professionally. This shouldn’t be surprising really. Generally speaking if someone is going through the trouble of actually writing an article on a topic, it’s probably safe to say that they enjoy reading about the topic. Write what you know, etc.

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.

Web development can be a bit of a beast, at least from the perspective of a programmer who is aware of the limits of his brain.

Back in the good old days, you could build entire desktop applications with one programming language, C++ or whatever that may have been. Whether the code you were working on was for the presentation layer or deep in the business logic, you were dealing with the same syntax, the same debugger and the same paradigms. The advent of large web applications completely destroyed that.

Depending on the language and framework you are using, any reasonable web application typically requires detailed knowledge of no less than four languages. HTML for your content, CSS for presentation, Javascript for any dynamic effects and some other language that you are using to do your server side processing. Technically speaking, two of these are not programming languages (HTML and CSS) as they offer no control structures, but they are still a syntax that you must keep in mind when working with them.

The problem with this is that no matter how good you are at programming, there is some mental overhead associated with the requirement to switch syntaxes in your head as you move from working on one aspect of the project to another. Generally speaking, most languages have their own distinct set of advantages and selecting the correct language for a given project is an important. That said, the more languages a programmer needs to use to work with a given project, the less likely they are to be an expert in all of them. This is an important enough point to note that it is corporate policy at Google to work with one of something like four languages. (Steve Yegge talks a bit about this here)

So I’m going to postulate that keeping the number of distinct languages that are needed to keep a given production application working and maintained to a minimum is an important consideration. If your project is using the aforementioned three web presentation languages, then a mixture of PHP, Java and Perl on the server side, you have dropped a large brick wall in front of any developers new to the system and added additional mental overhead to working on the project even for your top developers.

The grass is greener…

Which brings me to the Google Web Toolkit (GWT). I have used this in a few projects now and am fairly comfortable with the framework. I can safely say that I know it very well from an applications development perspective. When I first started using it, it was like magic. I got to write and debug Java code, which I was very familiar with, but when I was done, I could compile the project and run it in a browser with the same functionality.

The more I used it, the more I began to feel that I was actually more productive with it than by writing straight HTML/CSS/Javascript and tying that to a servlet or JSP based back end. I will emphasize that this was a ‘feel’ more than any sort of hard numbers, but more on that when I get to the criticism part of this post.

I’ve rambled before on some of the problems that I have with Java and was looking around to try out a new web application framework. I settled on Ruby on Rails to build Gifti.ca and I do really enjoy working with this framework. It has often been said that there is nothing like moving to a new language to show you deficiencies in the one you usually use, but the opposite is true as well. You see, with Rails, I was back to how I originally worked with web applications, four or five languages. This was when I had my ‘ahah!’ moment about the GWT and what it was that I really enjoyed about it.

Java, simpler?

In this case, yes, with the GWT, you need to work with two languages, Java and CSS. You can build an entire web application with the GWT and the resulting HTML that you actually put into the page is absolutely minimal. For all intents and purposes, you link to the Javacript file that the GWT generated for you and the entire application merrily builds itself in the web browser. For the most part, the major browsers work fairly interchangeably as well. The generated code is quite fast, better than humans can generate according to the Google propaganda and I have no reason to doubt them.

You do need to keep a handle on the CSS, but even then, a number of the classes have methods which allow you to programatically set various alignment parameters and the like so those can be taken out of the CSS as well. The AJAX functionality they have baked into the framework plugs into a servlet container so beautifully I’d be hard pressed to come up with a simple reason not to use Java on the server side with a GWT front end.

Eliminating two of the languages that you need to keep in mind when working on a project is a huge benefit mentally speaking. Fewer major context switches when going from layout to client side logic to styling meant that I found it easier to stay in the zone. This is why I need to make intelligent arguments with myself when starting up a new project as to why I’m not immediately firing up Eclipse and coding up a GWT project.

But…

I have some concerns about the framework. I feel more productive when I am using it, but I know that I spend longer building the user interface than I would have with a plain old fashioned web application. On the other hand, the UIs I tend to build with the GWT are more sophisticated. It is a balancing act. While I never bothered to keep any statistics, I would be surprised if the GWT was any more productive than anything other web application framework.

There is one very serious problem with the GWT and I have no real idea how to address it at this point, which is why my latest project isn’t using it. The GWT makes it easy, very easy to build your entire application with it. If you deploy a website built entirely with the GWT, search engines will not be able to index you. At least, not yet. All of your content will be buried in the compiled Javascript which in turn means that unless the search robot is running a full Javascript engine, you are out of luck.

Worse, if you want to support a version of the site that actually works without Javascript, you are left with writing another front end for the application entirely from scratch. My experience has been that this is painful.

Which also really means that before you jump into using the GWT for a given project, it pays to know your audience. For a general purpose web application that is to be used by a large and diverse group, the GWT is probably not the best choice. This is double so if the web application is geared more towards searchable content such as a blog. If you are building an intranet application or know for a fact that the clients that you are interested in will be running a full featured browser, then the GWT is an excellent technology to choose to go with. It’s probably also going to work rather well in an environment where web searchable content isn’t terribly important, a mashup with Google Maps or something along those lines.

Anyhow, long and the short of it is that I will continue to use the GWT for projects for the foreseeable future, it’s just too powerful for me to ignore. Being able to effectively ignore HTML and Javascript for a certain class of application is highly appealing to me.