Monday, March 28, 2011

Monoglot Developers are like Stereotypical Arrogant Americans

This post is partly because of some responses to a blog post over at Expensify and I apologize if it appears to be a bit of a troll. I saw the heated responses from ticked off .net fan boys and stopped to think for a minute. Why don't I use windows for development any more?

Just so everyone understands, historically I've used windows since around 1992 and Linux from about 1994 onward. For MANY years I tinkered with linux as a hobby, but did the majority of my work on windows, mainframes, mini's, or "real" unix. I made my living writing Delphi and VB desktop software for quite some time, I'm a certified MSSQL DBA, and I still use MS Office and Outlook on a daily basis. I also have a copy of visual studio and tinker around with it on occasion. But since about 2006, I've used Ubuntu Linux with GDM as my full-time desktop and my development efforts have always been much broader than simply the Microsoft ecosystem.

Why is this? Well, I guess I know there's a larger world than the windows desktop. For example, I have 6 computers, 3 TVs, two satellite receivers, 4 phones, a nook, a Yamaha motif keyboard, some gaming systems (PS3, WII), and some Linksys (Cisco) wireless routers... and NONE of them run windows. All of the them either natively run on a variation of Linux kernel or I can load a Linux variant on them to reconfigure them in a manner that suits my need. As a specific example, I've loaded dd-wrt on my router to change it into a secure bridge to extend the range of my wireless network.

If I focused on being the best visual studio developer in the world (C#,F#, VB.NET/etc), I suspect I would be inclined to never tap into this wider world of technology. I supposed if I were really adventurous I could attempt to load windows on my Linksys router, but I'm frankly the legal ramifications could be significant as Microsoft doesn't seem to like you using their stuff unless you pay them for the privilege.

As another example, Let's suppose I'm doing some cross platform mobile development. Right now that means at least iPhone + Android + Blackberry. As a guy who's been knee deep in Java, I can immediately use two of these platforms... as a javascript+html guy I can target all three... as a ruby guy I can target all three AND be cross platform. In addition, as a Linux guy I can get cheaper rates on amazon EC2 instances AND easily create secure scripts to deploy/undeploy and reconfigure them on demand.

Using Microsoft tools, I admit that I can still get this done, but now I'm paying everybody and their brother for licenses (monotouch, monodroid). Don't get me wrong, I'm willing to pay for good tools (intellij for example), but using Linux/OSS software, I don't HAVE to because I can get 50 different variations of eclipse for free... or just use emacs or vi.

Additionally, because the Linux/FOSS ecosystem is so diverse, I get to choose between a wide variety of solutions for any particular problem I'm trying to address. In the windows world, you typically only get core OS updates from ONE vendor and you have to wait for them for fixes. Even if you're willing to fix the problem for free and donate the solution back to them you are typically restricted from doing this (Unless you pay them a bunch of money). Put in this perspective, why would ANYONE ever want to put themselves in this situation?

The only reason that comes to mind is ... Marketing.

Microsoft (like IBM, Oracle, and others) has spent a tremendous amount of time/energy convincing anyone who'll listen that using their tools is the smartest, easiest, most economical way to go. This means and individual developer doesn't need to worry about those problems and they will continue to be in demand as long as the vendor is still in business.

As a lisp developer, you may be able to to build the most awesome hyper-scalable, flexible, and reliable solution in the known universe, but you're going to spend a large majority of your time convincing other people that they aren't making a mistake. If you're a C# developer, you don't need to convince anyone of anything... you can point to dozens, if not hundreds of reports, white papers, and power point presentations explaining why using C# is the BEST way to create a hyper-scalable, flexible, and reliable solution in the known universe. Better yet, these reports are vetted by professionals employed by a multi-billion dollar software company.

From another perspective, I feel as though developers who ONLY use Microsoft tools are similar to what folks around the world call "Arrogant Americans". This is the type of person who lives in Peru for a year and NEVER learns any Spanish, or visits France and always orders Cheeseburgers (or only eats at McDonalds). People who use Linux are more akin to world travelers, after living in Peru for a year, they speak fluent Spanish (because they already knew it) as well as a bit of Quechua. In France, they hit a different bistro every day and can identify which region the Camembert they had at lunch came from.

My aspiration is to be the technological equivalent of the world traveler and while I know a lot of smart developers who use Microsoft tools, I know a lot more smart developers who use a wide variety of tools. The folks I don't understand are the ones who think they've found the one tool that should be used for every job and spend time telling everyone else they're using the wrong when they don't use that particular tool.

Friday, March 25, 2011

Hard problems versus hard solutions

Many problems software developers are called on to solve are "hard problems". By hard problem I mean that the necessary compute power to solve the problem is high and there is no known solution that can reduce the overhead. An example of this sort of problem would a variation of the traveling salesman problem.

On the other hand, developers also called upon to solve what I would term simply "difficult problems". Difficult problems are different in that the solution is difficult for humans to comprehend, but they are know solutions that can be implemented easily at minimal cost and overhead. An example of something like this would be determining the latitude and longitude of an address in the United States. While this requires a large amount of data should you try and solve it on your own and it would be likely impossible for a human without a large reference library, there are FREE software solutions that do this very well and very rapidly.

The last and most problematic grouping is what I call "hard solutions". These are situations where someone has taken a difficult problem, treated it like a "hard" problem and (usually) through tremendous effort, built a hulking monstrosity of a quasi-solution that "is stupid, but it works". A shining example I routinely see in my line of work is software that uses the wrong paradigm to solve the problem it's supposed to be designed for.

For folks who don't write software for a living, this is the equivalent of using a hammer to pound screws. Yeah, you can do it (ask my son), but it's a hell of a lot easier to use a screwdriver. The challenge is being able to explain to someone furiously hammering on a screw that there is a better approach.

Thursday, March 24, 2011

Example of the difference between Ruby and Java

Having worked extensively with both ruby and java, I thought I'd share some interesting differences between how one can approach solving problems in the two languages.

Let's take a common example of a function that will take a variable number of arguments and return a string with all non-null values separated by commas. We'll start by just using the core runtime and see what we can do.

Here's the Java example:
public class StringJava {
    public static void main(String[] args){
        System.out.println(printComma("test1","test2","Test3"));
        System.out.println(printComma("test1",null,"Test3","Test4"));
    }
    public static String printComma(String... names) {
        StringBuffer buff = new StringBuffer();
        boolean first = true;
        for (String str: names) {
            if (str != null) {
               if (first) {
                   buff.append(str);
                   first = false;
               } else {
                   buff.append(','+str);
               }
            }
        }
        return buff.toString();
    }
}

Now the equivalent in Ruby:
def print_comma(*data)
  data.compact.join(',')
end
puts print_comma "Test1","Test2","Test3"
puts print_comma "Test1",nil,"Test3","Test4"


Ouch! It actually gets much better, because if you really need this sort of functionality a lot,you could just add the method directly to the Array class and do this in ruby:

class Array
  def comma_join
    self.compact.join(',')
  end
end

puts ["Test1","Test2","Test3"].comma_join
puts ["Test1",nil,"Test3","Test4"].comma_join


The latter approach would simply be impossible in java, but with just a little extra effort, allows you to enhance your ruby Array class to give you some very useful functionality.

At it's core, ruby is geared toward rapidly producing compact code and enables developers to modify their environment to support just about anything they want to do. Java, on the other hand, is geared more toward following a lowest common denominator standard at the expense of being more verbose and not allow developers to expand the language to meet their needs.

I'm not suggesting ruby is superior in all cases, but from a flexibility and development effort perspective, there really isn't any fair comparison, ruby trounces java in almost every respect.

Monday, March 21, 2011

Excellent customer service requires fixing broken windows

Organizations that excel at customer service all have something in common, customer service is absolutely pervasive. Everyone understands they have a customer and are interested, empowered, and enabled to serve their customers to the best of their abilities. On the other hand, companies that have a poor customer service culture may have large numbers of folks who really do care and really do a great job, but a few key folks who are slacking can bring the whole organization down dramatically.

As a recent example: Suppose an oil change shop has stellar oil change technicians, BUT, the folks who fix the computers are "not so good". How long does it take until the oil change guys are not stellar any more and are instead spending their time complaining about the computer guys? Just as bad, how long until the the oil change folks realize that no matter how well they do their job, the customer is going to have a bad experience because the computers don't work right?

The precedent for this phenomenon can be found in broken windows theory. In short, this theory postulates that one broken window in a neighborhood can lead to a rapid downward spiral of neglect if not repaired quickly.

Allow any sort of poor customer service will change the social norms in your organization and spread rapidly just like a neighborhood with a few broken windows will quickly fall into disrepair. You cannot have good customer service if your INTERNAL customers are allowed to be treated poorly. Put another way, if employees are allowed to treat each other poorly, how can one expect them to treat customers well?

Saturday, March 19, 2011

This difference between agility and speed

There are there are two complimentary factors that contribute to apparent speed.

First, there is raw speed. This is the ability to move in a straight line a certain distance in a certain amount of time.

Second, there is agility. This is the ability to change direction quickly and react effectively to new situations.

From my perspective, agility is the superior attribute, though both are important. To illustrate why, I'll quote Helmuth von Moltke the Elder by making the statement "No plan survives first contact with the enemy". Following this adage, it's easy to see how raw speed can actually become an impediment should you be speedily moving in the wrong direction. This can be further aggravated if you are able to move quickly, but unable to change direction.

Changing gears to software development, many folks confuse agility with speed. They get sold on the idea that software agility will somehow make their development faster. This is really not true and is selling the advantage of agility short. When focusing on agility, you will lose focus on raw speed and a side effect can be that you effectively move slower. What you WILL gain, however, is the ability to move in the appropriate direction at the appropriate time and make course corrections as necessary.

Friday, March 18, 2011

Change your change management process to support agility

Most organizations of more than one or two people need some sort of process to facilitate change. It really isn't feasible to have 20+ ( or 2000) people all doing their own thing without any way to coordinate things. In order to manage this, organizations invariably institute change management or change control processes.

What often happens is that these processes get focused on eliminating or mitigating the NEGATIVE aspects of change and very often ignore that changes also can have a POSITIVE aspect. In the end, many places end up crystallizing their process, it grows out of control, and it becomes difficult or impossible to create any change without the entire process breaking down.

Why does this happen?

I believe the the fundamental problem is that most organizations ignore the necessity of some sort of change management process (other than ad-hoc) until a dramatic event causes them to rethink their approach. Once this disaster happens, the positive aspects of the previously uncontrolled environment are oven overlooked to make sure they have limited the possibility of bad changes. They often very effectively create processes that bring safety by way of limited change.

Now, instead of making the mission something like "Facilitate positive changes by limiting the negative impact of bad changes", the focus is almost always on something more like "Limit bad changes by making more people be involved with the process". Once you look at the contrast and you can see that there is a "glass half full" approach and a "glass half empty" one. After years of "limiting change" being the driving force, many places end up in a situation where a simple change that could be done by one person in 5 minutes, ends up taking 2 hours spread across 5 teams and 10 people.

This illustrates the second, more insidious part of the problem. Change management processes often become a tool to distribute responsibility. While this can have a positive effect, often it leads to extra expense and time. For example, mandating that it takes two people to launch a nuclear weapon is probably a good thing, BUT, require two people to type a simple memo is probably not the best idea.

Here are a couple of simple ideas to fix this problem:

#1 Change the mission to focus on the positive aspect of change and relegate the negative aspect to a secondary role. Maybe change the name to "Change facilitation" instead of "Change Control".

#2 Take a realistic assessment of the cost of the existing change control process and fairly and objectively weight this cost against the cost of the negative thing you're trying to eliminate. Remember, don't just measure the time it takes to "fill out the request", there's the time to "PROPERLY fill out the request", time for "n" number of people to approve the request, time for someone to implement the request, time to review that the request was properly implemented. There's also the cost of the tool and it's maintenance (or worse yet, the cost of NOT maintaining it). Also be keenly away of the error rate for the existing process or system. I often see people who are shocked when, after assessing their process, they realize that they have a 25% error rate... often this means that a change takes 25% longer and costs 25% more than they originally expected.

#3 Take a realistic view of how much the missed opportunity costs are. At some point, delivering twice as much product may actually outweigh the cost of many catastrophic failures. After all, many organizations survive for years or decades with a bunch of cowboys who really want to do a good job.

#4 Don't be lulled into thinking a complicated highly ceremonious change control process is somehow superior to a simple uncomplicated solution. Often it's better to simply have good traceability and be able to clean up troublesome matters after the fact than it is to require multiple sign-offs and redundant/ineffective approvals for simple things that have negligible impact to your business.

In short, you should use your head and make sure that your change management process isn't getting in the way of being able to respond to business opportunities in a timely and effective manner.