On Polish Notation in Software Design

I was looking up Polish Notation, as I remember hearing about it.

And it turns out Polish Notation is actually, basically, when you think about it, exactly how programming languages in my experience work.

For example:

x − 5 6 7

Is polish notation for:

(5 - 6) x 7

This is very very difficult to understand for someone like me who is absolutely not used to Polish Notation.

However, when I write this down in programming language method calls, everything becomes crystal clear immediately.

multiply(minus(5, 6), 7);

For some reason, the statement above makes perfect sense to me.

Likewise as in the Polish Notation, in software design method-calls, the sequence of statements is unambiguous.

With the infix notation, parentheses are required to override operator precedence rules.

Both in Polish Notation as in programming, this does not seem to be required.

References

Wikipedia - Polish notation

https://en.wikipedia.org/wiki/Polish_notation

Java is pass-by-value!

Java is always pass by value, with no exceptions, ever.

From the JLS¹:

When the method or constructor is invoked (§15.12), the values of the actual argument expressions initialize newly created parameter variables, each of the declared type, before execution of the body of the method or constructor.

What this means is that the parameter is actually a copy of the value you provided. Hence, Java is always pass by value.

It is the same for the programming language C³.

It is the same for JavaScript⁴.

Confusion

The following quote from the JLS² causes a bit of confusion in the discussion:

An object is a class instance or an array.

The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

So, yes, Java does use pointers (to objects). However, these pointers are passed-by-value! This is why you can change the contents of an object but never switch the object for a different object.

References

[1] JLS SE 8 - 8.4.1. Formal Parameters

http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.1

[2] JLS SE 8 - 4.3.1. Objects

https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.3.1

[3] Dennis Kubes - Is C Pass by Value or Reference?

http://denniskubes.com/2012/08/20/is-c-pass-by-value-or-reference/

[4] What's The Pointy - JavaScript does not have "pass by reference"

http://whatsthepointy.blogspot.nl/2013/11/javascript-does-not-have-pass-by.html

JavaDude.com - Java is Pass-by-Value, Dammit!

http://javadude.com/articles/passbyvalue.htm

StackOverflow - Is Java “pass-by-reference” or “pass-by-value”?

http://stackoverflow.com/questions/40480/is-java-pass-by-reference-or-pass-by-value

Professional Scrum Developer I

Well, I managed to get my certification for Professional Scrum Developer on Thursday, the 16th of July 2015. Wasn't terribly hard.

References

Scrum.org

https://www.scrum.org/

PSD I Assessment

https://www.scrum.org/Assessments/Professional-Scrum-Developer-Assessments/PSD-I-Assessment

Professional Scrum Developer I Certification List

https://www.scrum.org/Assessments/Certification-Lists?AssessmentName=PSD%20I

Should I use an ORM?

Martin Fowler has a very nice article about why you should use an ORM, when you should not, and what alternatives there are.

See http://martinfowler.com/bliki/OrmHate.html.

Of course, as I have often said (but not always, never always), think before you blindly pick something to use. Is it appropriate? Is there something better?

Are Comments Necessary?

There are a lot of opinions on Comments in code.

In the words of Uncle Bob¹:

“The proper use of comments is to compensate for our failure to express ourselves in code.”

Here are some things to remember:

• Code is Leading.
• If comments and code do not match up, the comments are wrong.
• Code is always current, comments age.

There are two ways we can deal with unclear source code:

1. add comments, if the source code is unclear
2. refactor the code, if the source code is unclear, until the code is clear

The second option seems the best.

However, if the code is abstract, but the implementation refers to a (potentially complicated) knowledge domain, comments are a requirement.

However, sometimes the code should follow the knowledge domain. You try to implement the Knowledge Domain as faithfully as possible, to sort of map it one-on-one, if possible. If that succeeds, what you end up with is a Domain Specific Language (DSL).

Example

For example, in my job I work with valuation of houses. There are several characteristics that account for the value of a house.

• location
• quality
• maintenance
• appearance
• purpose
• facilities

Now, these individual items were stored in the record for a House.

Here is roughly my iterative software development written out:

1. I added comments on each of these (on the getters and setters) to indicate that it was a value characteristic. (instead of, for example, an address, price, year of construction, etc.).
2. I thought about it, and decided that this was a group of related data.
3. I made a class ValueCharacteristics, that contained all these.
4. I removed the comments.

Added bonus: once a value characteristic is added or removed, the different places where this will impact my code are much more clearly visible.

Conclusion

The steps you take can be generified as follows:

1. If the code is unclear, try and add comments.
2. Then try and think how you can change the code to better reflect the comments.
3. Change the code.
4. Remove the comments.

Comments can cause us to think about the code we produce.

Always keep in mind, if you have to add lots of comments to a piece of code, perhaps it is time to refactor instead.

I think that comments can still provide insight in "why" we do things, whereas the code only tells us "how" we do things.

References

[1] Clean Code - Chapter 4 - Comments

Robert C. Martin (Uncle Bob)

Rubber duck debugging

A colleague of mine pointed me to a Software development method called "Rubber Duck Debugging".

Besides being very funny, I thought it was a great idea, and I see the added value in it. Check the wikipedia¹ link below to find out more.

References

Wikipedia - Rubber Duck Debugging

http://en.wikipedia.org/wiki/Rubber_duck_debugging

The Pragmatic Programmer: From Journeyman to Master

Andrew Hunt and David Thomas

My Enum Frustration

At work, there is a bit of Legacy around.

The following example of several Enum classes we have, is what is currently frustrating me (and I try actively to change them).

Let's enumerate (oh, look, I made a joke) the issues:
Replacing magic numbers with constants and enums is, of course, one of the Good Things^tm.

But in this example, they seem to have totally missed the point.

Not only have they replaced magic numbers with "magic enums", it's an eyesore to use the underscore in the Enum instances.

When you have to take refuge in the use of underscores to make things work, it is a sure sign that you are doing something seriously wrong.

getAsModifableSet()

At work we have taken great care to limit access to a Set of values, as elements of the set have constraints between each other, that need to be sustained.

So any call to retrieve a set, is always done using Collections.unmodifiableSet.

public Set<T> getCycles() 
{
  return Collections.unmodifiableSet(cycles);
}

I would have been much more at ease, if we had also decided to make the elements of the set Immutable Objects, but alas, this is the status quo.

As it is right now, it's possible to change the attributes of the individual elements, and so break the constraints between them.

Surprise

Imagine the surprise of my colleague, when, out of nowhere, he found the following method:

public abstract SortedSet<T> getAsModifableSet();

The typo in the name is actually in the code, I swear! My grasp of the intricacies of spelling is beyond reproach.

And it returns a very implementation-specific Set as well.

And it's public too.

I'm sure there are always good reasons for these things, but sometimes I'd like to run my head into a wall.

Scrum

I managed to take a Scrum Foundation course (a one-day course to introduce me to Scrum) on Thursday, July 31st 2014 at Xebia¹.
The trainer in question was Martien van Steenbergen².

Introduction

So basically Scrum is one of many implementations of the Agile Software Development Process.

I'm going to write some things that I picked up on and I found to be important:

If you look at a graph of the adoption of different technological innovations in the US over the last 100 years (television, radio, internet, etc), there are a couple of things worth noting:

• every innovation follows the well-known S-curve, a few early adopters, followed by the herd of followers, followed by saturation of the market. This is remarkably the same for both old innovations of long ago, and new innovations of today
• the S-curves are becoming more steep, network effect increases quickly, the market becomes saturated much more quickly, i.e. new things get adopted much more quickly and easily
• there are more S-curves in a given period now then there were in a similar period in the past, i.e. the rate of new innovations is increasing

Hence one of the reasons why everyone is looking for new ways to manage, and much better yet, facilitate, change. Scrum seems to be one of the possible answers.

The portmanteau chaordic refers to a system of organization that blends characteristics of chaos and order.

Some characteristics of Scrum

• 10% is bureaucracy, so in a two week sprint, your meetings/standups/etc add up to about a workday.
• we complete what we start
• a stable team is very important
• manage work and processes, but lead people.
• a scrum team consists of 6 people on average, give or take one.
• trying to estimate things correctly right at the beginning, is impossible
• keep the process (scrum) lightweight
• keep it flexible, which means, don't plan too much ahead, things will change
• keep your focus, which means, if you do plan, plan for short periods of time, for example a sprint, and keep your focus during that period. Become flexible once more when the period comes to a close. In effect you are trying to be both flexible and efficient at the same time.
• take responsibility for tasks, instead of getting tasks assigned to you
• feedback is very important, without feedback you do not know if things are working correctly or if things need to be adjusted
• we should talk about work during standups, and think less in terms of "what did I do, what am I going to do".
• history is important, without history we cannot make predictions on the future
• based on history you can make predictions if only one of the following are fixed: deadline or scope. See the Iron Triangle⁴

Glossary

sprint³

a time-box in which we commit to doing a list of things

velocity

what tasks can we complete during a sprint

delta

a change to a current situation, basically everything is a delta

product backlog

a list of all things that need doing

product owner

owner, responsible, employer, takes on risk, competence, available

scrum master

monitors the performance of the sprint(s), velocity

development team

performs work

Quotes

“If you chase two rabbits, you will catch neither.”

- Russion proverb, on context/task switching

“If the rate of change on the outside exceeds the rate of change on the inside, the end is near.”

- Jack Welch, former CEO of General Electric (on adaptability)

“Big Projects usually fail, regardless of process. The secret to project success is to strongly recommend and enforce limits on size and complexity. These two factors trump all other factors.”

- Henrik Kniberg (on limits)

“It doesn't matter who does it, as long as it gets done.”

- ? (on team effort)

“Where there is no standard, there can be no Kaizen.”

- ? (on continuous improvement)

References

[1] Xebia - Summer Special Scrum Foundation Training

http://training.xebia.com/summer-specials/summer-special-scrum-foundation

[2] Pearl Language

http://pearllanguage.org/Home

[3] Scrum.org - Scrum Guide

https://www.scrum.org/Scrum-Guide

[4] Wikipedia - The Iron Triangle

http://en.wikipedia.org/wiki/Project_management_triangle

Scrumalliance.org

http://www.scrumalliance.org/

Scrum.org

https://www.scrum.org

Wikipedia - Agile software development

http://en.wikipedia.org/wiki/Agile_software_development

Alan Klement - Replacing User Story with Job Story

http://alanklement.blogspot.nl/2013/09/replacing-user-story-with-job-story.html

eduScrum - Dutch website on using Scrum in the classroom

http://eduscrum.nl/

The getKanban Board Game

http://www.getkanban.com/

The New New Product Development Game

by Hirotaka Takeuchi and Ikujiro Nonaka