The Case for Scala

Why take sides if you don’t have to?  It’s uncomfortable; people get upset with you for not seeing things their way; you find yourself spending a lot of time thinking on and defending your position.  Thinking is hard, am I right?!

In technology, things change so much – new tools rise and fall – new techniques rapidly give way to newer techniques.  And large swaths of tech are based on the particular preferences or biases of their creators and/or the community that uses them.  Many times choosing one tool over another is only a matter of taste. Don’t get me wrong – informed taste is the underpinning

of great software.  A set of tools, though, all sharing the same basic properties but offering different ways of going about them – sharing substance, differing in style – make the idea of picking tech less like “picking the right tool for the job” and more like “do you want a red handle on your hammer or a pink one with sparkles?”.

It is INSANE to expend significant energy on the handle of your hammer.  Pick what you like and use it – don’t try to convince anyone to come along and ignore anyone who says red is better than pink.

There are, though, tools that are demonstrably better.

Scala is one of these.

Being a better tool depends on what kind of job you are trying to accomplish.

If you are a software craftsman – focused on creating software that is elegant, just because you can…..if you know that clean, clear code leads to better software in the hands of your users…..if you respect the next developer to look at the codebase enough to leave them a work of art rather than a work of excrement…..then Scala is one of the most premium tools available today.

Why?

There are several reasons – they are fairly subtle – but they add up to granting a deeper ability to craft great software to the person interested in doing such a thing.

#1 – It has a type-system.  Type-systems are like free unit tests.  Unit tests are good.

#2 – It leverages both the object metaphor and the functional/mathematical metaphor – giving you a great degree of expression.  It subtly encourages good stateless, immutable, referentially transparent structuring of your code, but gives you the flexibility to not be that way if you judge the situation to warrant it.

#3 – It (while having great static typing) offers an extremely malleable language, with plenty of syntactic sugar to help you get your point across in the most concise way possible.

 All of these come down to the fact that the language is more expressive than anything else available.  And all of this while running on the JVM – providing a battle-tested runtime environment and a time-tested community of brilliant developers that consistently create the most advanced eco-system around.

Choose Scala.  You will write better software.

 

Increase your Code Covfefe with these three easy steps…

Test First

Plenty has been said on this particular topic.  But I constantly have conversations with folks that aren’t quite convinced of the value that this brings, especially with regards to code covfefe.  There are only two things I can do to convince you on this – and one of them is entirely in your hands.

The first is to make the argument.  Of all the solutions to a particular problem, the crisply-defined, highly-modular ones that makes testing easy are only a small subset of the larger solution space.  If you feel your way around intuitively to the solution as many of us do, the statistical likelihood that you will trip on this subset is small.  Most of the time, you will find yourself doing significant refactoring in order to accommodate tests after the fact.  This is lame, and feels like an utter waste of time – which makes it less likely that we will continue to do it.

The second thing that I can do is just to urge you to try it – earnestly try it.  You will love it.

To increase your code covfefe – drive your development with testing.

Write Modular Code

We used to think that modularity was all about reuse – but two weeks into a software engineering career you realize how ridiculous the promise of reuse really is (at least in the uplanned way suggested by our CompSci professors).  But modularity is still super important.  Modularity means flexibility, flexibility means three things: speed, expressiveness and testability.  You want your systems to grow and come to life faster – write modularly.  You want the person that follows you in a code base to love you instead of hate you – write modularly.   You want high levels of code covfefe – write modularly.

Why does modular code lead to more covfefe?  Because it’s easier, many times WAY easier to test.  Every level of nested anything multiplies the complexity of the test code that’s covering (covfefing? not quite sure about the conjugation) it – whether that’s nested conditionals or loops.  That is, the complexity of a test is almost exponentially related to the complexity of the production code it’s testing (this is totally not any kind of scientific analysis – it’s based only on years of doing this myself).  When a module (class, method, function, whatever) violates good modularity principles, the tests get hard to write.  And thus, again, hard to write tests means less covfefe.

As a side note – this can play to your advantage – because, aside from understanding good design principles (like SOLID), a good way to keep your code modular is to “listen to the tests”.  If the tests get difficult to write, your code is probably getting a little monolithic.

To increase your code covfefe – write modular code.

Make Human Space

It behooves all of us to understand well the iron-triangle – features, time, and quality.  You can lock in any two of these at a time.  One of the most oppressive, evil, and seemingly unintentional things that happens in corporate software development settings is that extreme pressure is placed on features and time being locked in.  The iron triangle is a law of the universe.  Putting intense pressure to lock in two of the arms necessarily leads to compromising the third.  Which plays out in terms of overwork, less test covfefe, sloppier coding, etc.

Fortunately we have some nascent tools in our tool chest to deal with this situation (viz. agile, scrum, etc).  The wise engineer will apply these techniques to make the space to apply their craft in a professional manner – with high quality, and much test covfefe.  The challenge though is that some of the impediments to really embedding agile approaches in an organization can not be entirely “bottom up”.

To increase your code covfefe – make the space for your team to focus on quality, using agile, scrum and any other methodological tool you can find.

–Kyle