What I Learned This Week (Week 51/2013)

Each week I write a blog post which describes what I learned that week. I write these blog posts for two reasons.

First, I want to keep track of my personal development and writing regular blog posts is a great way to do it.

Second, I want to share my findings with you. I hope that you can use some of them in your daily work.

Let's get started and find out what I learned in week 51.

Note: I will not publish a new learning diary next Sunday because I am on a Christmas holiday. I wish you all merry Christmas (or happy holidays if you don't celebrate Christmas) and happy new year!

What I Learned in Week 51

First, Implement proper error handling.

Sometimes when we implement a feature, we don't pay enough attention to error handling. This is an easy mistake to make because it is kind of natural think about the happy path first.

After all, isn't this what our client wants?

No. It is not. Our client wants us to ship a working feature which has a proper error handling.

What is proper error handling then? That depends from the application but I am pretty sure that showing a general error message for every possible error is not what proper error handling means.

Of course there are situations when we have no choice than to show a general error message but we should also understand that these errors are very rare. Most of the time we can (and we should) show an appropriate error message which actually describes what the problem is.

Actually, if we think about error handling only when we have started to add features to our application, we are probably already too late. We should have designed a common error handling mechanism which is used throughout our application.

This ensures a consistent user experience, and more importantly:

It saves our time (and nerves) because we don’t have to investigate our log files every time when a user sees our general error message.

Second, Always be demoing.

If you are using agile software development methods, you are probably aware that at the end of a sprint, you will gather together in a sprint review meeting where you will show what you have done during the sprint.

If this is the first time when you demo the new features to the product owner, sometimes the product owner decides that she isn’t happy with outcome. This means that have to make some changes or even rewrite some feature (or features). In other words, instead of adding value, you have added waste.

Is this how agile should work?

No. I think that one of fundamental principles of agile software development is to minimize waste.

The best way to do this is to show the new feature to the product owner as soon as possible and ask for feedback. If you are on the right track, you can keep going forward. However, if the product owner sees that something must be changed, you can make that change immediately when it is easy and fast to do it.

If you keep doing this on a regular basis, you will notice that the amount changes made after a spring review meeting will decrease because the majority of changes were done during the sprint. This means that you have successfully reduced the amount of waste added during the sprint.


Third, You are an expert. Act like it.

Don't be the guy/girl who is afraid of saying the word no to your customer. And if you are this person, think about the following:

If you just do what your customer asks you to do, you are very easy to replace. There are many developers out there who can do the same thing cheaper than you can.

Of course, you can always think that you cannot be replaced because you write good code. If you think this way, I have got news for you:

Every developer thinks that his code is special.

Are you really sure that your code is special enough?

Are you sure that your customer values good code more than cheaper price?

There is an "easy" way to make yourself harder to replace. You can start by following these rules:

  • If you think that there is a way to make a feature easier to use, speak up.
  • If you think that all required features are not needed, speak up.
  • If you think that the application is missing critical features, speak up.

Don't be just a programmer.

If you help your customer to create the best product possible, you are no longer a replaceable cog. You are now a valuable member of the product development team.

Fourth, Everyone is a newbie at some point.

Because I write a technical blog, I get a lot of questions which could be categorized as "newbie questions". I will answer everyone of them but naturally sometimes it takes some for me to do.

Why do I do this?

I am not doing it because I am a saint. There are times when I am very frustrated to see a "newbie question". It is normal. After all, I am just a human.

The reason why I do this is that I still remember what it was like to learn programming without internet.

It was tough. It was so tough that I didn't manage to solve all my problems. I either figured out a workaround or abandoned my idea. That is "normal" when you don’t have the skills needed to turn your ideas into a reality.

A few years ago I noticed the buzz about rockstar developers. A rockstar developer is a superhuman who can solve write code hundred times faster than a mere mortal and solve problems which seem impossible to solve.

I don't believe in this bullshit.

I value collaboration and learning more than I value fairy tales about superheroes who can single-handedly save a doomed software project.

I believe that every great software developer realizes that the people who ask "newbie questions" aren't stupid. They ask questions because they are trying to learn, and it is our responsibility to share our knowledge forward.

After all, didn't we learn from other developers who were willing to share their knowledge with us?

Fifth, Well planned is not done.

We have a saying here in Finland which goes like this:

Well planned is half done

I disagree with this. Although there are many areas in life where proper planning is needed to prevent disasters, software development is not one of them.

In software development the goal of "proper" planning is to eliminate the unknown before any code is written. That is an impossible task and maybe that is why all projects which start with upfront planning are very very VERY EXPENSIVE.

Let's think about the phases of an imaginary software project:

  1. You have to create a perfect plan. Because taking everything into account is very hard, creating the plan takes a lot of time and money.
  2. You have to implement the software by following your perfect plan. The problem is that because you cannot take everything into account during the planning phase, you have to have a bureaucratic change management procedure (and a change management budget). Again, you burn a lot of time and money.
  3. When the software is finished, you notice that the requirements have changed and you have to start planning again.

I am not saying that planning is not useful but you shouldn't overdo it either. If you aren't sure when planning is useful, follow these "rules":

  • If you are planning only because you have to write a written plan, you are on thin ice. Planning is useful. Plans are not.
  • If you cannot describe why you are planning without talking technical/business jargon (aka bullshit), you are adding waste. STOP DOING IT!

What Did You Learn This Week?

Share your learning experiences or other comments on the comment section.

0 comments… add one

Leave a Reply