Everything Looks Like a Nail

I've heard it before here and there, but it exactly describes how I feel working with Java for the last few years.

"If all you have is a hammer, then everything looks like a nail."

I've been writing code for over 20 years now; C, C++, Smalltalk, Java, C#, Python, Ruby, etc. When I went to school, we were taught Pascal, C, Cobol (now that sure dates me) because the school I went to wanted to get me ready for the "real world" and that world was using those languages at the time. Admittedly, I didn't learn much in school. I didn't learn much about computer science. I learned plenty about how to build simple CRUD applications using imperative programming languages. Sure, we all used SQL, but didn't spend much time understanding it. Think about programmers today, most know enough SQL to get the job done. How many times have you seen SQL stored-procedure code written... well... procedurally? I bet more than a few. Did you even notice? Did you care? I didn't. I should have.

Java Sucks

I'm not going to sit here and tell you that Java sucks, but... well... Java sucks. Why? Because there's no evolution of the language. Imperative only. Cruft everywhere. Powerless scoping rules. And, most importantly, it's limited my ability to think about problems in different ways. I naturally think procedural - give me Lisp, Haskell... forget it. I've inadvertently trained myself to only see nails.

Java is Powerful

Huge community. Many tested frameworks. I want to leverage that community, those frameworks. I want to make them better. I sure as hell don't want to start again. I'm not going to rewrite Hibernate. I don't want to rewrite Wicket. I don't want to rewrite JScience.

Why Not Ruby?

I was there for a while, but I can't stay. I really love the language. It' has almost everything I need. It has a large community. So why not? I don't want to invest my time into a toy. Sorry Ruby people, I only have enough bandwidth for one, and I see too many fundamental problems. No compiler. Not type-safe. (dodging bullets) No concurrency. Hey, I was in that community and put up with all those problems because I couldn't take Java anymore. Now I don't have to.

Scala

Scala, introduced to me by a colleague who's always on the lookout for a better way, seems to really impress. It's multi-paradigm; object-oriented, functional, concurrent. It's type-safe! Yeah! Powerful generics! Yeah! Closures! Yeah! Type-safe mix-ins! Yeah! Oh... did I mention... (cue the drum roll) it's Java! Can you imagine trying to write cross-cutting mix-ins in Java? Scala generates .class files that run in the standard Java 5 virtual machine. You want to leverage your favorite Java framework? Go ahead. No problem. What? You want your Java team to leverage a library you wrote in Scala? No problem. One drawback, and not really a language drawback, is the learning curve for all of us that see only nails.

Some of you are thinking "what the hell is he talking about?". "What's wrong with doing it the traditional way? 99% of the software we use today is built using imperative programming and they work just fine". Well yes, back some 2000 years ago, 99% or homes were built using straw and clay. They were just fine then too. Since then, homes have evolved because people wanted more. Today, people are smarter, tools are better. We want more.

Tools

Ouch. Scala isn't there. Getting better, yes, but it needs some time. Unless the tools get there, the masses won't come for the longer term. I won't come for the long term if the tools don't evolve. I've invested in Eclipse as a tool and a platform. For me, it's as important as the language - especially if the language is cumbersome. I'm not going back to vi and print statements. Forget it. I don't care how great the language is. Thankfully, Scala has an Eclipse plugin that at least gives me the critical stuff, i.e. debugger, syntax highlighting, etc. It's getting there. It just needs some time.

Give it a try.

Getting Real... Now That's What I'm Talking About

I've recently been thinking philosophically about the best way to build software, when I stumbled upon 37signals' Getting Real book. I decided to pick up a copy here because reading online for an extended period sucks.

I'm not going to sit here and tell you it's the Holy Grail but it's the Holy Grail. For the right type of business. Sure, this book is specific to 37signals' business, or shall I say companies who make a living selling service-based software for the masses. Regardless, take these points and interpret them for your business and you'll be better for it.

The following points, directly from the book, are "bang-on". I don't care what kind of software you're creating. These points make a helluva-lot of sense to me, because I've either lived either this side and experienced the joy or that side and experienced the pain. I'm not saying that I don't agree with the others points in the book, it's just that these are the ones that really shine for me.

Note: These are in the order as taken from the book

• Build Less
  
• Fund Yourself
  
• It Shouldn't Be A Chore
• Less Mass
• The Three Musketeers
• What's The Big Idea
  
• Ignore Details Early On
• It's a Problem When It's a Problem
• Hire the Right Customers
  
• Scale Later
  
• Make Opinionated Software
• Half, Not Half-Assed
• It Just Doesn't Matter
• Start With No
• Hidden Costs
  
• Done!
• Alone Time
• Meetings Are Toxic
• You Can't Fake Enthusiasm
• Less Software
• Optimize for Happiness
• Manage Debt
• There's Nothing Functional About a Functional Spec
• Don't Do Dead Documents
• Tell Me a Quick Story
  
• Tough Love
• Better, Not Beta

There are a couple of points of my own I'd like to add that may arguably disagree with a couple of points in the book.

Stay The Course

Be cautious about changing your mind. Being flexible is not the same as being schizophrenic. Embrace change when you know, not when you think. See out the decisions you've made. Test them on your market. If you hire the right customer, you'll find this won't be a problem for you.

Don't Be Lazy

Agreed, you won't get it right the first time, but don't let that be an excuse to being lazy. See the big picture when you're building an application and pay attention to what you're doing. Don't let the race to running software get in the way of quality.