Category Archives: change

How to never fail

In rock climbing, courses are graded based on their difficulty, and in general, the higher the grade the harder the course. There are several grading scales, where one of the popular ones is the Yosemite Decimal System. On that scale, the 5.12 grade is considered magical, and for many intermediate climbers it is considered to be out of reach.

Climbing - fall

For climbers aiming to beat the challenge of climbing a 5.12 wall, one of the more important lessons is: fall. The fear of falling during the climb stops you from trying difficult moves, keeps you from testing your limits and eventually prevents you from pushing your performance envelope. So – fall. Again and again, first in a controlled environment where you know nothing bad will happen, then fall from a little higher (you’re always connected to the rope, and you must always follow all safety procedures) – but trust your equipment and, more importantly, trust yourself.

shooting yourself in the foot.jpg

In Software development, there are many ways you can fail – you could miss deadlines, you could have bugs, the project could exceed its budget, the customer may not be happy with the results, and it could be all of the above. So we add guards – we create a project plan, get a bug tracking system in place, do automatic testing, make sure there are reviews and reviews of reviews, get a project manager, a program manager a product manager and development manager, make sure they all meet and update each other regularly, and we then add the secret ingredient – a buffer.

What’s good about buffers is that you can never have too many of them. And if you fail, the easiest way to learn from your mistake is: add some more buffers next time. The problem is, in my view, that we’re getting too used to buffers. At times we don’t even remember why we added some of them to begin with, we just know that if we don’t do another review, get another meeting in place or add some extra time – something really bad is going to happen.


No one likes it when bad things happen to them. No one like to fall. It hurts, and you could get injured. But aren’t we missing an opportunity to learn what we can really do? Isn’t adding another buffer a dangerous block to seeing what our limits really are?


I realize there are many open questions here (like: are the customers willing to pay for you taking extra risks, and should they? can you actually control the amount of risk being taken without getting yourself killed in the process?). It may be that when things get complicated enough, when the project becomes big enough, you just have to add brakes and balances, or you will cause more damage than good. But does it mean we have to give up on our full potential at this point?

So, one of your employees think they have a great idea…

In a marketing book I once read (entitled Marketing Managment (2000), by Prof. Jacob Hornik and Prof. Phillip Kotler) there’s a chapter about introducing a change into an organization.

Besides discussing various ways to do that, the chapter also talks about the forces fighting the change, and brings a list of ‘common yet effective ways to fight change’, here it is:

Employee: “I have a great idea!”

Manager – quickly choose one or more of the following responses:

  • It will never work for this organization.
  • We tried it before.
  • This is not the right time.
  • It can’t be done.
  • We don’t work that way.
  • We’re doing great without this.
  • It’s too expensive.
  • Let’s discuss this in our next meeting.

Java Language Change

I’ve been to JavaEdge 2008 last week, and while many of the sessions were interesting, I found the one about the Java Language Change particularly intriguing.

During the session 10 proposed changes were introduced, all of them minor by definition (as stated by Sun in the JavaOne 2008 TS-5881 presentation), and everyone got to (anonymously) vote.

Here is the list of proposed changes, and even if you don’t get to vote, I think it’s interesting and thought provoking:

1. Map-for-each:

for (String key, Integer value : map) {

2. For-each iteration control:

for (String str : list : it) {
if (str.length() > 100) {


3. List/map access:

List<String> list = ...
Map<String, Job> map = ...
Map<String, Map<String, Task>> combined = ...

String str = list[0];
list[0] = "Hi";
Integer value = map[str];
map["Hi"] = 56;
Task task = combined["Test"]["Monitor"];

4. Infer generics in declarations:

Instead of
List<String> list = new ArrayList<String>();
List<String> list = new ArrayList<>();

5. Multi-catch of Exceptions:

try {
catch (IOException, SQLException ex) {
// handle..

6. String switch:

String str = ..
switch (str) {
case "name":
case "surname":

7. String interpolation:

String name = ...
String Value = ..
String out = $"The value of ${name} is ${value}";

8. Multi-line Strings

String sql =
"""SELECT firstname, lastname, birth_date,
telephone, account
preson, phone, email

9. Resource management:

try (FileReader in = new FileReader(file)) {
} // and resource validation and release is done automatically

10. Null-handling:

Session sess = ..

String code = sess?.preson()?.address()?.postcode(); // if anything preceding ? is null, the result is null

What’s your vote? 😉