object HelloWorld extends App {
  println("Hello, world!")
}

In the Beginning

Looking at the “Hello, world!” example makes me reflect on my earliest programming exercises in high school.  I remember discovering how boolean logic, variables, and loops are the building blocks of a computer program.  Back then, software was simple.  Write code, run the program to verify it works, then print out the code for the teacher.  I never considered the maintainability of my design, the performance of my algorithms, or the mutability of state.  At the time, my biggest challenge was to write a Visual Basic version of video poker.  Yadda, yadda, yadda, if you would like to play a working version of the game, I encourage you to seek out other alternatives!

Software is Complex

Software is completely malleable and it disregards the laws of physics.  This makes software so much fun, but also complex.  For example, unlike building design, software design is unaffected by gravity.  The implication of having (nearly) zero restrictions on software design means software can become a warzone overnight.  People think differently, use disparate naming conventions, create leaky abstractions, and (sometimes) just write broken code.  If it was not hard enough to create maintainable code, consider all the business logic that is often times sprayed throughout the code.  Have you seen code like this?

def retrieveUserSettings(user: User): Set[UserSetting] =
  user.userType match {
    case ADMIN => settingRepository.findBy(user)
    case MANAGER => user.groups.flatMap(settingRepository.findBy(_))
  }

In this contrived example, why doesn’t the admin user have groups?  Perhaps originally, only admin users existed and admins did not need groups.  Then, a business requirement requiring managers and the ability to associate managers with groups was introduced.  Pressed for time, the hacky solution became production code.

In my experience, I have found that software evolves.  It constantly moves from one state to another.  Sometimes the move causes a few ripples, like a small refactoring to improve maintainability.  Sometimes the move causes a tsunami, like trying to support a new business requirement that invalidates existing requirements.  People do not set out to write unmaintainable code (contrary to what you may believe!).  Instead, the code grows to be unmaintainable.  In addition to a clash between requirements and maintainablity, there are also often conflicts between performance and maintainability.  Provided you’ve met your performance requirements, would you prefer to solve a problem with or without bit twiddling hacks?  In six months, how long will it take you to understand the following C code?

int x;  // we want to find the minimum of x and y
int y;
int r;  // the result goes here 

r = y ^ ((x ^ y) & -(x < y)); // min(x, y)

It doesn’t have to be this way.

Why Write about Software?

Just several years ago I knew nothing about software engineering.  Since then, I think I have collected enough crumbs of knowledge to declare, “I know something!”.  I am sharing my insights about software to help everyone (including myself!) create better software.  What does better mean?  I will be exploring how to answer this simple question.  And kudos to those who know the language that the first two examples were written in.

System.exit(0)