Geir Hedemarks blog

I have been getting more and more questions from both managers and techies about scala lately. Is this the time to switch to scala. This time, I am going to address the management/architect side of the question.

“Should I switch to scala” usually is the wrong sort of question. A better question is “what can I change that will improve my situation”. Techies usually have a habit of jumping the gun when it comes to technology-related issues. We dive right into the things we know best – the technology.

A lot of organizations are troubled by this. Why does the question come up at all? What does not work out for your organization? Very often, the question is a variation on “we need to get stuff done faster, and once it has been delivered, it needs to continue working”. Fixing the things that will give the biggest improvement first is usually the way to go. So where in all this does Scala – or any other “cool” technology – come into the picture.

This is my preferred list of todos before starting to fiddle with the technology stack, provided there is a workable technology stack around:

• QA and testing. Many organizations do not have a workable regression test suite around, or have a regression test suite that gets in the way of changing the product. This will give a test workload that increases with the square of the number of features in the product. This will work out for the first couple of months, but the cost of not having a workable, automated regression test suite will quickly cause management or customer attention.
  There will still be a need to test every release. Regression tests are about ensuring that the stuff that worked in the last release is still operational. Anything that has been done in the current release, and anything that is of a visual nature, will have to be tested manually. Regression tests are there to reduce the cost of the tedious testing – the stuff that needs to be repeated every last release, and which gets bigger and more complex for every release.
• Requirements capture. Many organizations are not very good at selecting which requirements should be implemented, and in what order. I think this is a sign of office politics – someone is out to increase their dominion without regard to the health of the organization. Mental visions of big, flaming eyeballs, orcs in their thousands, and tall, forbidding, black gates are appropriate here. The organization will never have any chance at being remotely efficient before the evil dominions have been reduced to a size where the overlord has to explain why there is a need to have big, black, forbidding gates inside of the organization, until the orcs turn out to be kids with poor complexions and butter knives, and the overload has to pay for the effect his black gates have on the organization from his pre-existing budget.
  Of course, the evil overlord may be the head of IT. Nothing makes an evil overlord like an IT guy. We are too well read in the science-fiction and fantasy worlds not to have picked up a thing or two. There needs to be a balance – read the Recluce books by Modesitt for a fantasy introduction to balance, otherwise have a go at “User stories” by Mike Cohn.
• Knowledge  management. This has nothing to do with ITIL processes. This is about one part of the organization knowing what the other does. It is about developers understanding how tasks are performed by users of the system. It is about one developer being able to pick up where another left off. It is about management being willing to listen to arguments in non-managerial language.
  This is in direct conflict with being “more efficient” in the short term, and is therefore a problem with some current managerial trends which tend towards optimizing short-term profits to pump stock prices, even at the expense of long-term profits. Developers should get time out to clear up costly “technical issues”, they should work tightly with the users of the system so they understand what is needed, and so on. They are not creating new functionality while they are doing this, and will therefore be “less productive” and give less impressive results in the next financial report.
• Lifecycle management of the software is something almost no development organizations think much about. I have had people yell at me when I asked what the life expectancy of a system was projected to be. The system was rewritten from scratch two years later. Switching technologies is not an interesting question compared to throwing away all the code every two years. So – how long is the system meant to live, and what should it cost? Should it be possible to make it into a product?
• Personnel issues are a recurring problem in our profession. We had a visit from Uncle Bob a month or so ago, and he said something about not having weapons in the same room as two senior developers. Sadly, he was right – some of us are hard to work with. These issues can overshadow any benefits gained from moving to a new technology.

Any organization that does not have good control of all of these issues, or who have taken steps to get them under control, should not be thinking about adopting Scala. Fixing any of the above issues – if they apply to your organization – is going to have a much bigger impact than Scala ever will. So – make sure that introducing a new technology is a good idea.

Moving to Scala is going to require investments in new knowledge, there will be technical issues that will have a direct cost both in time and money, there may be downtime. Scala is also a very immature platform compared to Java or .NET. The benefits and risks should be carefully weighed before going for any new technology. This is my own list of pros and cons for Scala right now:

• Pro: The language is “more orthogonal” than Java. This makes for a language that may require fewer workarounds and sticky-tape solutions.
• Con: Developers have tendency to abuse new and “cool” technology in an attempt to show off. Unreadable or unmaintainable code is a problem whatever language it is written in.
• Pro: Scala can reuse existing libraries from the java world. This should improve efficiency, especially if there is existing knowledge of Scala libraries in-house.
• Con: There is very little knowledge about what bugs may be caused when using Scala with these old libraries. This, sadly, is a also developer-dependent. The organizations that are already using Scala will have solved their own teething troubles – but this does not mean your organizations will not create the same kinds of problems.
• Pro: The designers of Scala have created a language that is less verbose than Java. This is significant because Java applications tends to get unmanageable by sheer codebase size.
• Con: The development tools available for Scala are horrible. The best one while I am writing this is IntelliJ, with Eclipse in second place. I don’t like the compilation model of IntelliJ, so I am sticking to Eclipse. Netbeans is not a contender until the Oracle noise has been resolved.
• Pro: Developers want to use Scala. Hiring talent is probably going to be easier, depending on what the previous technology in use was.
• Con: Scala might not make it. What happens if Scala turns out to be a fringe language in two years? The risk of having to do another rewrite in another language should be factored into the decision to move to Scala. Personally, I believe in Scala, but there are no guarantees.

Now, don’t misunderstand me. I am going to try to find the time to write a small application in Scala during the next half year or so. I like the language. I am looking forward to getting rid of the non-functional fluff that is irritating me in Java. I just think organizations wanting to move to Scala should have a clear idea of why they are doing it, and what they will have to sort out along the way. Having a strategy or at least an explanation to the challenges posed here is a way to actually get to experience the benefits made possible by Scala.

Oh, and have a happy new year.

This entry was posted on Saturday, January 2nd, 2010 at 3:00 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.