Free Code

Lately, I've been really paying attention to how much functionality you can reuse for free from major players. For example, you can check out the various Google APIs (http://code.google.com/)and the Yahoo! User Interface Library (http://developer.yahoo.com/yui/). These libraries are free, released via Open Source licenses, and offer ridiculous amounts of functionality.

As a developer, I love the idea of being able to leverage the work of other people. Most of the time, this is hard to do because so much of the code that everyone else writes is crap. ;-) But seriously, there is even a name for this, we call it Not Invented Here (NIH). The premise being most developers like to know exactly what their code is going to do, so using someone else's code can be hard.

In the case of the big boys like Yahoo! and Google, it becomes a lot easier to trust that the code is going to deliver expected results and not be malicious or buggy. After all, when it is provided (and used) by a company with billions of dollars of online reputation to uphold, you can pretty much bet they've tested it.

Which isn't to say that just because they are all that, you don't need your own bag of chips, they have their issues too. Dependency and version issues, occasional bugs, and warped programming models are abundant. But in the end, you are definitely getting your moneys worth.

The chart at the top of this post is generated using the super cool (and free!) Google Chart API which means I won't be paying for Dundas or ChartFX licenses again. You can find the details at http://code.google.com/apis/chart/.

Running The Gauntlet

This week I had the chance to discuss using Team Foundation Server in a large team setting specifically as concerns Build and Deployment.

As I was organizing my thoughts to answer a question about check-in policies, merging and branching, and so forth and I kept coming back to my guiding principles:

• The Build is the build. There is only one Build.
  
• Build anywhere you like, as much as you like, but it only counts if it is in the Build.
  
• If it doesn't work in the Build, it doesn't work.
  

Now I am certainly familiar with having to manage simultaneous release schedules, juggling branches, and so forth, but that doesn't mean I like it. I absolutely support the mainline concept. Much like the Highlander, when it comes to the build, there can be only one.

We could argue that there are many techniques to allow these fancy behaviors but that doesn't make it okay. Just because you can do something, doesn't mean you should. Experience tells us that if you have a big team, you can't afford to have anyone interrupt the flow of the system. This includes breaking the build, causing failures of critical tests, etc. When more people or organizations are involved, the cost increases.

In the agile communities there is a push towards Continuous Integration (CI) which is really an attempt to implement the Only One Build concept as an ideal. When you can do it, you should. When the amount of code grows or the number of loose connections increases this can be cost-prohibitive, primarily in time. Compiling 1.8 million lines of code is going to take a little while regardless of how big the build machine might be. And when it comes to running Build Verification Tests, these problems are compounded. Especially if you are using disparate services that are loosely coupled.

The idea behind CI is to bring compilation and integration issues to the attention of the team as soon as possible thereby minimizing distribution. Going beyond that are tools that would actually test code entering the system before check-ins occur and reject or accept them based on the results. With TFS policies this is fairly straightforward to set up and an open source effort has begun to bring this to life. You can find out more about this effort at http://www.opengauntlet.org/.

If you prefer to wait until this functionality is built-in, you'll be glad to know that the next product release most likely will include a similar feature with a working title of "Gated Checkin".

3 Pass Coding

Back in the day at Microsoft we used to look for and train developers who were 1 pass coders. In today's world everyone is a 3 pass coder and they are starting to drag me down with them.

Let me explain the difference between a 1 pass and a 3 pass coder.

When you are writing code there are several layers (or aspects) of design and implementation activity that have to be balanced. Firstly, you have the very simple, but often disputed, question of whether the code will meet a functional objective. This is often referred to Working. If the code won't perform the purpose the code is intended for it Doesn't Work and the rest of its qualities aren't relevant. Assuming that it can be made to fulfill its intended purpose (i.e. it Works), then the other two aspects suddenly become important.

The next most tangible aspect of coding is the speed at which the code will execute or process units of work, transactions, operations, etc. Regardless of the velocity or metrics implied, the measure of this aspect of coding is generally called Performance. Making something Work is the first step which is immediately followed by does it Work Fast.

Lastly you have a host of intangibles of varying degrees of importance. There can be many tangible expressions of these intangible attributes used by different people at different times. The number of comments, the readability of the control flow, the robustness of the error and state management, and the lack of logic or bounding bugs; are all examples and all of which are related. We put these closely-coupled items in a big bucket called Quality. This may also referred to as Maintainability, Elegance, etc. If you can make it Work, and make it Work Fast, can you make it Work Correctly?

Now when someone starts out coding, they generally are capable of keeping only one layer in their mind at a time. They start by making the code Work. They just want to see it do what they think it should do. Of course, once it does that, then they immediately concern themselves with making it Work Fast. It is about this time that consumers of their code start exercising the possibilities and uncovering flaws and boundaries of the code. So a review of code usually focused on specific bugs or concerns is undertaken until eventually it is determined the code must Work Correctly. This lifecycle usually involves 3 distinct reviews or Passes on the code. It is written, then reviewed for performance or capacity, then again for bugs and boundaries.

On the other hand, a 1 Pass coder will have such a clear picture in mind of the code, the control of flow, the logic loops, the impediments and enhancements to speed, the boundary conditions and bug potentials, that the exercise is compressed into a single Pass of coding. All the work is done upfront in the design and in the construction of each line so that intangibles are caught during the initial pass.

At least that's how we used to do it. It's how I used to do it.

Now engineers are so woefully under-skilled. They aren't forced to learn logic or bit math. They didn't take any classes on algorithm design or perform exercises on bug potentials. They just want to see it Work and then have testers tell them what else needs fixing. If you want it to Work Fast they just buy bigger boxes or more of them. The days of discipline are gone.

When I have to oversee their work or explain an implementation I find myself being forced to speak in terms of what it takes to make it Work because the other layers trip them up. If I show them tight, elegant code with robust error and state management and efficient control of flow, they can't read or follow it. When I assign bugs they want to debug and watch the code execute because they can't find the bugs by reading the code. I have to worry about losing my own skills just working alongside them.

Yesterday for a personal coding project I came across a bug running the program and my first thought was to set a breakpoint and see what happened. I wanted to slap myself out of the chair! I'm better than that. I can READ and understand code. Which doesn't mean I don't take advantage of the debugger, but it shouldn't be my first thought. I'm a 1 Pass coder and I intend to stay that way.

Google Gets Dirty, Takes Away Soap

Google has decide to discontinue access to their SOAP API. If you are already using it you can still continue to access it, but by not issuing new keys, they are effectively killing their support.

They've made a token effort by suggesting you use the AJAX API, but that is hardly the same thing as everyone knows. The AJAX API hardly even qualifies an a real API, it is more just a widget you can add to your pages.

The do have some other interesting APIs, but it seems like they are starting to close off access to their core data. Interesting to wonder what that might portend, eh?

Reality Check

Most of the time I don't give much credence to the talking heads in fields like technology. Basically to be competent in this field requires a commitment to be doing that fundamentally restrictions your ability to be talking. So it is generally okay to assume that if you are primarily a talker, you are not really a doer and everything you say needs careful scrutiny. On the other hand, there are those who don't particularly talk a lot and you know it is because they are getting stuff done. When they do open the kimono, it is best to pay attention. Especially when their views align with my own. ;-)

I don't see aspect-oriented programming escaping the "academic ghetto" any day soon, and if it does, it will be less pervasive than OO. When it works, aspect-oriented programming is elegant, but it's not clear how many applications significantly benefit from its use. Also, with AO, it appears difficult to integrate the necessary tools into an industrial-scale programming environment.
--Bjarne Stroustrup

A great example quote, from a Technology Review article, of someone bringing some practical reality to the world of technobabble. Personally, his use of "academic ghetto" about made me fall out of my chair I was laughing so hard. Truth is so much better than fiction.

Thoughts?