I have been attending talks on functional programming languages at NFJS over the past couple of days. I have to admit it, I am really taken with the power of Scala and Clojure to tackle problems that Java cannot handle. I even purchased a Clojure book to add to my “languages to take a good hard look at” stack. I really believe that it is true that the functional languages have a lot to offer.
However, let’s not loose track of one really powerful tool that the Object Oriented world provides to us. This is the way to model the world in a more natural way. Since we do this all the time in Java and other object oriented languages, we take it for granted now. But the advantage that this modeling the world in our mind and our code is tremendous. One of the biggest constraint on developing software is the ability to hold in our minds the mental model of what the code is doing and how it is doing it. Once, you do this – you “know the application”. Having the ability to break the world up into chunks that more easily fit allows us to more naturally build applications without the complexity drowning us out.
I am wary of the temptation to “throw the baby out with the bathwater” to go to pure functional and leave objects behind. This is way Scala seems like a pragmatic solution, since it allows you to turn the dial back and forth from the Object Oriented way of doing things to the functional side.
That being said, I still intend to learn Clojure next instead of Scala. Why? Because to learn a new language that is a new way of thinking, I would prefer not to have an alternative way to fall back to old familiar ways of thinking. That way you can really get a new perspective on things to see what the true functional side has to offer. And no, I am not hard core enough to learn Haskell.
One thing is for sure. The future is multi-core.
I think most developers are familiar with getting in the “zone”. The place you get when you are totally in focus and in the flow of development. The code comes quickly, the ideas are together and everything just seems to work. It is the sweet spot of productivity. I have found the best way for me to get into the zone is to put on my headphones, arrange some uninterrupted time and just start going.
There is another zone, however, that I think is just as important. This is getting into the zone with the customer. At the beginning of a project, or even just joining a new company, you have to get to know your customer. It involves a lot of learning the business rules, processes, and just plain communication style. In these early stages, there is a bound to be some misunderstandings. This is where the iterative development process really shines. With each feedback cycle, you get closer and closer to thinking and understanding what the customer and the business wants and needs. As your project development you can start be in such harmony that you can consistently develop what they need on the first try and even anticipate areas of improvement that will delight the business user. To me, to get into the development zone and the customer zone at the same time is the really sweet spot.
What happens if you are just in you development zone and not in the customer zone? Well, cranking out beautiful code that the doesn’t serve the business needs is not beneficial. Your code can be the most beautiful and elegant ever produced, but if it doesn’t do it’s job, what use is it? What happens if you in the customer zone and have achieved a mind meld with your user and have internalized exactly what they need, but you get never get into your development groove. Let’s say for the sake of argument, you are constantly being interrupted and pulled into pointless meetings, so you can never concentrate long enough to get into the groove? The code doesn’t write itself. It remains unrealized and of course that business never realizes the value either.
So, I think, really you need to get in two zone simultaneously to be the most productive developer that you can be. Luckily, following an agile development process will get you there.