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.

 

The Craft of the First Creation

Tags

design, Unit Test

Jobs aimed for the simplicity that comes from conquering, rather than merely ignoring, complexity. Achieving this depth of simplicity, he realized, would produce a machine that felt as if it deferred to users in a friendly way, rather than challenging them. “It takes a lot of hard work,” he said, “to make something simple, to truly understand the underlying challenges and come up with elegant solutions.
Walter Isaacson

---

Stephen Covey, in his uber-important “The Seven Habits of Highly Effective People” lays out a general principle that is as true in Software Development as it is in any other craft. The principle I’m referring to is that of the “First Creation”. You always create a thing twice. The first time, you create it in your mind, the second time you create it out in the world.

This principle is one that is very poorly understood by software developers. The reason that it is poorly understood is likely due to the lack of friction that exists between our ideas and and getting a representation (however crude) out into the real world. That is – with minimal explicit thought we can start typing into our ide – and get the Hello World version of whatever we have in mind to create in very short order.

We’ve all seen this – she sits down and immediately is able to accomplish things without really thinking things through. Though in her defense – there were man-eating dinosaurs after her.

And really – isn’t that how we love to start working on a project – we take pride in being able to sit down at a computer and start typing – and magically things begin to work. Not only do we love the praise and the instant gratification that comes from this – even on our favorite movies and TV Shows, this is how computer work happens. And of course – it’s really the obvious way to begin when we first learn to code.

So what we end up doing is a very quick, very intuitive “First Creation” – and then riding off like Code Cowboys into the sunset, sure that we’ll save the world.

Problems…

There’s a problem that comes from this though. A quick, intuitive first creation gives us only an intuitive, vague understanding of the problem space. If we haven’t explicitly thought through all the road bumps we are likely to run into – we will only have a gut feel for them.

Intuition is a powerful thing – and our ability to solve problems without a complete understanding of them is one of the things that is really cool about being a Human. However – though you CAN solve a problem without understanding it entirely does not mean that you will solve it in a particularly good way.

Practically speaking – if you don’t spend some time *explicitly* thinking through a “First Creation” – you will invariable start coding like crazy only to run into many, many decisions to make that catch you by surprise. You will be able to solve them – but because you didn’t think clearly through things to begin with – the decisions will undoubtedly compromise your structural vision (which again, you’ve made implicitly).

The end result is – you end up with code rot long before you even get anything into production.

The State of Things…

Is the world going to end if you don’t put in the effort to perform a “First Creation”. No.

Will you limit your craft and fall short of your potential. Yes.

The systems you write DESERVE to be elegant, well-crafted works of art that not only perform the function for which they were created but also clearly communicate your intent to the developer that comes after you. Even if that developer is you – don’t you want to inherit elegant, well-structured code that takes minimal effort to understand?

Or if you like thinking in terms of negatives – the warning I’ve always heard is – Code like the developer that is going to follow you is a murderous madman that knows your address.

The Solution…

Part I

So how do we do this first creation? Am I suggesting months of documents and powerpoints to ensure we have exactly the right thing before we begin to code – NO!!! IN NO WAY AM I SUGGESTING B.U.F.D. (Big Up Front Design).

What I am suggesting is explicit forethought – I usually do this with some scratch paper and a pen – or with the ubiquitous white-board. Write out an object model – ensure that your objects are abiding by SOLID principles – and think through all the interactions until you feel you are comfortable and have a handle on everything within the scope of what you are building. Then start to decompose … then, and ONLY THEN – Code.

This could take minutes – or it could take a couple of days – but every developer involved in actually writing code should be comfortable with things prior to coding. Will it change along the way – certainly. Should you be explicit in your “First Creation” with regards to solutions to any changes – yes.

Part II

The first section here discussed having a First Creation for the whole feature you are creating – another aspect of the First Creation in software development is at the granularity of the actual code. When you create a class or a method or even a for loop – you should explicitly think it through before writing code. This would be obnoxiously difficult if we didn’t have a technological tool to make this possible.

That technical tool is called the Unit Test. When we write a unit test – we are creating client code for our actual production code. This forces us to switch perspectives to think about what it is we are creating and how it completes its mission. This change of perspectives allows us to quickly and with minimal context shift do a First Creation for every bit of code we write.

Conclusion…

Creating elegant, simple (but not simplistic) solutions to the problems we face is hard work. It’s ultimately far more satisfying (and profitable) than hacking code together quickly and throwing it out the door. If you are up for it – if you are up for doing the work to intimately understand your problem space and deliver amazing solutions – well you are well along on the way to creating more incredible software!!

And the world is a better place when we create more incredible software!!

Happy Coding!!
-Kyle

More Important Than Code (Dealing With Change) – Part 2

Tags

agile, change, influence, leadership, project management

Change is painful for everyone – and (as we discussed in Part 1) a little sensitivity to this fact helps a lot.  But understanding others when they are going through change is really just a small piece of a much larger topic – how to work with and influence others.

mgcpuzzles.com

These guys did not influence each other very well, did they?

Influence is not about manipulating others to get them to do what I want – it’s figuring out how to work with others to get what we both want.  And this is a primary ingredient in dealing with the incessant change that we pointed out in Part 1 is so much a part of creating software.

So let’s step back to some of the big examples of change we’ve been throwing around.  Imagine again that we are introducing a new tool – a new source control tool like git, or maybe a dependency management tool like maven.  We now know that this is going to be uncomfortable for everyone involved, but if we can appropriately influence those around us to work toward the common goal, we can make it more successful in spite of the discomfort.

It’s important that our software efforts are successful – because they make our lives better and the lives of those around us better.  I’d say it’s so important that we should learn to wield all the influence we can muster with those that are involved in these efforts.

Influence is a skill – one that you can practice and improve at.  And in seeking to become better in this arena, it’s important to understand that many people who think and write about this topic actually call influence by another name…Leadership.  In fact one of my favorite authors, John Maxwell says that “Leadership is influence, nothing more nothing less”.  I know many of us software-types might associate the word leadership with pointy-haired managers and over-ambitious MBA holders.  But we shouldn’t short-change ourselves by unnecessarily avoiding a topic that can have a very direct effect on the important software projects we are working on today.

To repeat myself a little here, influence and leadership fundamentally deal with how we interact and connect with other human beings.  Human beings are notoriously analog in their interactions – and often behave in unpredictable, confusing ways.  The study of how to work with these odd creatures as such is then much more of an art than it is a hard science.  So, the way you can become better at it is by learning from folks who are good at it, and by practicing it.

I am not by any stretch of the imagination an authority on leadership – I simply know the effects that the little bit of ability that I have in this area has had on my software as I’ve developed myself.  It’s been amazing.

So – one place to start is with the author I mentioned earlier, John Maxwell.  His new book is actually on the topic of how to grow ourselves – which is obviously helpful for those of us that hadn’t considered it something that we actually need to work on.

http://johnmaxwellonleadership.com/2012/09/04/we-reach-our-potential-through-growth/

Mr. Maxwell has also written extensively on the topic of leadership:  The 21 Irrefutable Laws of Leadership, Developing the Leader Within You, and many others.

I also recommend Dale Carnegie’s “How To Win Friends And Influence People” as well as Stephen Covey’s “Seven Habits of Highly Successful People”.  There are countless books (and other media) on the topic – the more you can learn, the better of your projects will be.

So remember – because of the ridiculous amount of change involved in software creation today, being able to influence and work together well with your fellow developer, your user base, or any stake holder is an invaluable skill that will reap great rewards.  But you will need to work at developing this, and that means getting as much information on the topic as you can find and practicing.

More Important Than Code (Dealing With Change) – Part 1

Tags

agile, change, programming, project management

Change does not roll in on the wheels of inevitability, but comes through continuous struggle.
-Martin Luther King, Jr.

---

Dr. King was right – change is not easy – it’s a continual struggle.  Creating software, almost by definition, is change.  So, to start with, we need to understand that creating software means that we are the agents of change and thus the instigators of a continual struggle.  This struggle is the cost of making the world, or our little corner of it, better in some way.

Why is change a struggle?  Because it makes people uncomfortable.  Why does it make people uncomfortable?  Because it asks us to change our habits.  Habits take a lot of time to develop and are costly to create (time is, in fact, money).  And whether we know it or not we value our habits greatly – whether it’s stopping for our morning latte, or coding on our favorite IDE.

So let’s take a break right at this point.  The first really important thing to realize is that by asking folks to change, we are asking them to discard valuable habits and replace them with new ones.  That is, we are asking for something valuable from another person.  We might as well be asking them to hand over a sizable amount of money (the amount of money in this analogy might vary depending on just how important or deeply ingrained the particular habit is).  So thinking about this – would we lightly ask someone to put a significant amount of money on the table, regardless our expectation of a high return?

So if we can get our head around the idea that change is asking people to put something valuable on the table then we are ready to look at how dealing with the effects of change so powerfully determines our ability to create incredible software…

I think we’ve probably gotten used to it – everything related to technology changes extremely rapidly at this point.  And it’s only getting faster.  In software, new tools, libraries, frameworks, and even programming languages pop up and then quickly become mainstream.  While how aggressive a particular team is at keeping up with the latest trends varies widely, even the slowest adopters couldn’t be called slow by objective standards.  In order to take advantage of new efficiencies and avoid having their stack become obsolete and unsupportable – teams adopt new/different technologies pretty rapidly, these days.

So, no matter how change-averse you are – I would argue that if you’re making software, you probably are still dealing with a fair amount of change on a regular basis.  The questions is really – are you dealing with it well – or are you letting it suck the life out of your development team?

A team that is handling change well may still be uncomfortable with change at times – but will be hungry for it, excited about it, and invigorated by it.

A team that is not handling change well will probably have something of a knee-jerk reaction of fear and dread when the idea of potential change is discussed.

So think about the last time your team decided to implement a new practice such as pair programming or test driven development.  Or when a tooling change was made – perhaps using a new version control system or a new type of server platform.  What was the general reaction like?  Did the team rally – did it flounder?

As you can probably gather by this point – this particular “people concern” affects every part of software in a big way.  It is “More Important Than Code” in a lot of ways and it is definitely a tool that we all need to have in our software tool belts!

To that end, part 2 of this post will continue by explaining not only how to deal with change but how, with practice, it can be used to multiply our ability to create incredible software.

The Software is an Afterthought

Tags

agile, Introduction, programming, project management, quality, scrum, software

My favorite TV series ever (with the possible exception of The A-Team) is Burn Notice.

It is about a likable, good-natured, if not slightly single-minded ex-spy named Michael Weston.  Michael was kicked out of the CIA, so while not trying to get his job back, he spends his days righting wrongs perpetrated against the good citizens of Miami.  There are a lot of car chases and explosions along the way.  It’s fantastic.

Throughout the course of the show – he gives spy tips and explains the situations he’s in as voice-overs while the action continues.  In one situation he’s trying to find (and stop) an assassin that is about to do what assassins do.  He explains, “Assassination is 1% shooting, 99% preparation, anticipating moves, devising approaches, recruiting sources, finding the perfect opportunity so the bullet is almost an afterthought.”

The same holds true for software.  Putting an actual production system into play should be almost an afterthought.  Unfortunately a typical software practitioner tends to spend 99% of their time shooting and only 1% preparing.  Fortunately the consequences of this misplaced priority aren’t as extreme as it would be for the assassin that made the same mistake.

However, if we want to produce incredible software – we have to (almost obsessively) prepare.  But what does this look like in practice?

This is where it gets interesting.  Software is nowhere NEAR as simple as many people think it is – technologists included.  This is probably why practitioners spend so little time preparing – why spend a lot of time on something that is so straightforward:  you write some code, you make sure it works, you set up a server, you deploy – easy as pie.

I am being slightly sarcastic here – but in all seriousness – those basic steps are the only ones that seem to get any press.  This is likely due to the fact that if you miss any of the aforementioned steps, you simply won’t be able to move forward at all.  And further, for a trivial software engineering exercise, these steps are all you would need.  However – this blog is called “Software For Profit” – and few profit from trivial exercises in software.

So to get past the basics we need to realize one major thing – software is about both people and technology.  So, creating great software comes down to balancing people concerns and technology concerns.  These concerns tend not to be particularly obvious – and even less obvious is the interplay that exists between them.  Managing them properly can lead to multiplying value – managing them poorly can lead to severely diminishing value.

For example – if introduced correctly, a high-powered source code management tool may multiply developer productivity.  If the discomfort of such large change (a people concern, for sure) is not accounted for – the same tool could significantly reduce developer productivity.  Another interesting example is the interaction between software design and development process particularly within agile methodologies – a modular system with a well laid out object model is inherently much easier to clearly decompose and therefore much easier to deal with in a scrum planning session and during a sprint.

This blog will be dedicated to identifying a wide array of these people and technology concerns, explaining their interactions and suggesting ways to optimize them so that we can all write the best possible software.

Here’s to creating incredible software!!