Thursday, October 7, 2010

He Man Java Haters Club



If you ever watched Little Rascals, you know about the He-Man Woman Haters Club. Well now that there are a billion new languages for the JVM, I'm starting to see another club, the He-Man Java Haters Club, and it has a similar oath. First, I'm not saying Java is the one true language that replaces all others. Learning new languages is important. And its important even if you don't use them right away because it gives you a new way of looking at a problem, a new way of thinking. As Einstien said, "Problems cannot be solved by the same level of thinking that created them."

For instance, after I learned a little Haskell, I think I wrote better methods that didn't have side effects. As much as I would enjoy coding for a while in a Lisp based language, I realize that most of my work involves coding Java and since I am a consultant, most of my future work will also involve Java. So I try to include the essence of it in my programming until I can get a chance to program in it.

Does that make Java stupid or ugly or whatever negative adjective you can think of? The answer is no. Of course it has limitations, so does every language and if you don't see that you are missing the point. Java is an object oriented language, this is where it excels, it has a mature set of tools and a ready source of developers. That is why it is popular for enterprise level programs that need to model a business problem. That is why it works well in implementing the Model in the MVC pattern. It's also why new disruptive websites programs that need to evolve quickly and are starting to be written in other languages.

But hating Java is like hating the hammer because you can't use it as a screwdriver. Mainframe programming is still being used in some big companies. What made it a good tool before is why it is still around. It may have gotten a bad rep for trying to do everything, and it took it awhile to find its niche, but for certain problems it still works well.

So, learn the other languages. Figure out what they do well and add them to your toolbox. But don't do the same thing that the old language did, which is try to do everything with your shiny new tool. Don't be a one tool programmer, because if all you have is a hammer everything looks like a nail.

Saturday, May 15, 2010

The Code is Not a Requirement Document

The other day I got one of the infamous requirements conversations that developers have every so often. It goes like this.

BA - And your change should not affect the existing behavior of the system.
Developer - OK, what is the existing behavior of the system.
BA - UM, look at the code
Developer - So what is the final result so I can look at the code.
BA - UM, look at the code
Developer - What should I tell QA to test
BA - UM, look at the code


The code is not a requirement document. Unless the code is very simple, you cannot effectively tell what the final behavior is because the code is not a final state, it's a state machine. It takes inputs in the form of data and delivers an output. Based on the inputs it can deliver an infinite amount of outputs. This is why we have bugs in our software. We don't intentionally write code that will break, its usually that some input in the software takes us down another path that we didn't expect.

Yes, I will admit that many times this is possible and even probable for a method, maybe for a class, but it doesn't tell us all the interactions of our code. There are a host of interactions, UI, database, middle ware, back-end processes, etc. Add to this the ability of callbacks, dependency injection or manipulation of the data somewhere other than in the code and it quickly gets complex.

Even if I can decipher the code, it might anchor me into a horrible solution. Maybe the code I'm looking at is the worst possible way to solve this particular problem, maybe there are simpler, easier solutions, its hard to step back and look at a problem once I see the current code as the "solution".

I use the analogy of a car in the parking lot. I can tell you a lot about that car, make and model, where it is parked. However, if you ask me to start defining rules of behavior, basically the requirements, I would start to struggle. It would depend on the driver, which way do they drive to work, maybe what time they drive to work. What is the average speed, the maximum? Do they make right turns on red? Do they take the long way, because there is always congestion on the freeway? I would probably get many of the rules right, but that because I know how a car works and some of the driving laws in my area. But if its code that I don't know very well, then all bets are off.

Am I complaining, maybe a little. But I do enjoy working with this level of detail, that why I do this and get paid for it. Its complex and messy and hard, but it's also fun. As much as I enjoy untangling some code, it doesn't tell me what the intent was or what the business is trying to accomplish. Looking at the code to see what the requirements are works in some cases, but most of the time we just need to do the hard work of hashing out what exactly it is we are trying to program.

Thursday, April 15, 2010

Spicy curry for my javascript

I had came across currying when studying functional languages, and I struggled a bit with the concept. I always saw mathematical examples and complex explanations, but never a concrete example of how and why I should use it. Until the other day when I had an Aha moment.

So what is currying? It is a partial application of a function. For example you have a function that takes 2 arguments and you only pass one and wait until later to supply the second argument. This could be on a callback or in a closure.

Its also useful the other way, if you have a function that only takes 1 argument and you want to pass another argument. This is where I had my moment of zen. I was trying to get an event into a DWR callback function. The problem is the function only takes 1 argument supplied by the DWR call.

Since we are using Prototype, I discovered Prototype had a curry function also. By the way here is a good reference book on Prototype. I am starting to find the more I learn about Prototype the more I like it.

Well, enough talking, time for some code. For simplicity, I included the prototype.js in the same directory has my html.
<script type="text/javascript" src="prototype.js"></script>
<script type="text/javascript">
function baseMethod(msg){
    alert(msg);
}

baseMethod("Normal operation");

function wrappedMsg(times,msg){
    for(i=1;i<=times;i++){
        baseMethod(msg);
    }
};
var newBaseMsg=wrappedMsg.curry(2);
newBaseMsg("Curried Operation");
</script>
In the code we have a function that takes only one argument, like the DWR callback function. By wrapping the code I am able to change the behavior of the function and the use the newBaseMsg wherever I would use the DWR callback function.


If you aren't using Prototype don't despair. I found a good link that
explains it very well.
Replacing the prototype function with the curry function will accomplish the same thing.
<script type="text/javascript">
Function.prototype.curry = function() 
{ 
  var method = this, args = Array.prototype.slice.call(arguments); 
  return function() 
  { 
    return method.apply(this, args.concat(Array.prototype.slice.call(arguments))); 
  }; 
}; 
function baseMethod(msg){
    alert(msg);
}

baseMethod("Normal operation");

function wrappedMsg(times,msg){
    for(i=1;i<=times;i++){
        baseMethod(msg);
    }
};
var newBaseMsg=wrappedMsg.curry(2);
newBaseMsg("Curried Operation");
</script>

I think we forget sometimes that JavaScript has many attributes of a functional language that make it very powerful and can provide some elegant solutions to some problems we have.

Tuesday, February 16, 2010

Information Architecture (IA) That Sucks Less

If you have ever went to a site that was hard to use its probably because someone left it up to the developers to make the site "look OK". Often as a web developer on a small team, we don't have the resources of large enterprises. Tasks like usability and design often fall to the developer writing the web pages.

Since I've found myself in this position more than a few times, I decided I could learn a little about these fields that might help me suck less at it. I found a book called . Its a great introduction to Information Architecture (IA),this is a fairly new discipline and there are many views on what an IA is and what it should they be. Are they the designer that focuses on the look and feel or in my case the developer that makes is all work together? It could be creating the content or focusing on usability. In truth its a little of all of this, that's why its so hard. Maybe some of the larger projects would need a formal position, but I think we can go a long way by learning a little ourselves and making the interface of our sites suck less.

Theory of Constraints and The Efficient Programmer

The Theory of Constraints is a management theory that comes from the book The Goal. Basically it says in a process there are a few constraints that limit how fast the whole pipeline works. An example in software development would be waiting on the database team to design the tables or the waiting for BAs to write the requirements. If they are the slowest point then it doesn't matter how fast we code. The book also talks about optimizing points in the process may or may not help the entire process.

Why is this? Imagine a factory floor that produces widgets. The process has to go through 10 machines. One of the machines is 1/2 as slow as the rest. Its obvious that this will result in everything piling up in front of the machine. However, what if some engineers tweaked another machine so it was 2 times as fast. First a backup would occur in front of the machine that comes after the machine that runs faster and the other thing is that the process is not any faster. Since we still have one machine running at 1/2 the speed it doesn't speed up the overall process. The most efficient use of our resources would be to optimize the slow machine.

How does this relate to being an efficient programmer. I've seen efficient programmers get their work done and always try to get more work. Their utilization looks good, everyone comments on how fast they go through the code. However, do they ask questions of the lead who is already swamped. Do they bother other resources that our busy with fixing priority defects, do they do anything to improve the process. In other words are they optimizing their work at the expense of the overall process. In the goal it suggests that it may be better to idle a resource rather than have it pile up backlogs. I'm not suggesting that the person sits and twiddles their thumbs. I'm saying they should be aware of what time and resources they are pulling to get their task done and is pulling those resources away the best for the overall project. Could they work on unit tests or conducting a spike on a new technology, updating documentation or somehow improving the throughput of the entire process instead of a laser beam focus on getting their code done. Could they look at who has the most work and pair program or take some workload off of them. I feel this would be a better use of their time.