Posts

Showing posts from March, 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

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 mos

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 = fal

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

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 tru

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 pre