The next Java – Scala

Martin Odersky developed the early Scala (stands for Scalable Language) in 2003. It’s taken a while to gain critical mass – but now that it has, I find it very exciting. In a nutshell this is taking Java back to it’s roots, trying to rid Java of the complexities it has gathered along the way (Has it been 16 years already!).

So what’s so exciting about Scala (pronounced Scar-la not scay-la)?

First of all – and being an object fan I love this – EVERYTHING is an object. Yes even primitive data types are now objects. So you can type the following in Scala and it will work:


The integer is converted to an object in the bytecode! Cool.

Secondly – it generates Java Bytecode, which means it runs on any JVM.

Number Three РNo Static methods, they are replaced by Singleton classes which are really easy to instantiate using the object statement.

Number Four – XML is a breeze with Scala, it makes it really really easy to read and drill down into XML streams

I’ll do a more in depth blog on it once I’ve had a chance to code up some examples. Check out¬† in the meanwhile to get to grips with it.



Complicated is not clever

There are many reasons why projects fall behind or fail altogether. I’ve talked about them before. Management and Employee buy-in. (Organisational Change Management) – bad Data Migration Practices and so on. If it is a technical project it can fall foul of “we don’t know how big it is, we don’t know how complex it is, but we know when it must be finished” syndrome. If you have a project that falls into this category you’re already at a severe disadvantage. You will uncover the real scope of the project as you go along so you have to start compromising early on.
Statements like “this will not fit into our timescale” should be par for the day. Reduce the scope to fit and make it clear upfront that this is the way it will be managed. If this is not acceptable and extra resources (not always a practical solution) can not be added, it’s time to walk away from this project.

I’ve mentioned the triple constraint before so I won’t labour the point here.

One way you can reduce the scope in a subtle way is to reduce the complexity. Complexity is a poison that eats into projects, increases TCO and can make a project a nightmare to coordinate, integrate and deliver. An Architects job should be to reduce complexity. period. If he or she can do that then half the battle is won.

A good developer is not, as some would have you believe, one who can deliver functionally rich, complex and “clever” solutions. Clever solutions are simple, elegant solutions that are easy to use and even easier to understand. There was a saying in the 60’s and 70’s that went along these lines:

If you can explain your system to your Grandmother – it’s a good system.
If your Grandmother understands it – it’s a much better system.
If your Grandmother designed it – it’s the best system.

In other words – it’s simple, elegant and to the point. Some complexity these days is unavoidable (security, for example). Most is completely avoidable.
A good developer and a good architect avoid complexity like the plague. They will argue long and hard to simplify processes.

If you are a client, let them simplify things as much as possible. Ask the question – “is this really needed?” – often.

Some complexity is acceptable – some people go as far as to call it “good complexity”. Personally I wouldn’t. Adding functionality that differentiates and puts your company ahead of others is acceptable complexity, but it must itself follow the rules of simplicity to become an elegant function.

The Global Simplicity index puts an estimate of $1 Billion dollars a year lost by the worlds largest companies, purely due to complexity.

That’s a lot to pay for someone to think you’re clever.

Leonardo da Vinci once said “Simplicity is the ultimate sophistication”.