What I Learned This Week (Week 39/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 39.

What I Learned in Week 39

First, Integrations are hard. Every time when I heard the sentence: “this integration is fairly simple”, I know that in 99 percent of the cases, the speaker has no idea what he is talking about.

Although it is true that some integrations can be easy and straightforward, often you find yourself in a situation where a “simple integration” has taken weeks or months before it is working properly.

One of the biggest problems is that the requirements of the integration often cover only the happy path. If you don’t keep this in mind, this might fool you to think that the work is done when you have implemented all requirements.

Guess what? It is just a good start!

The real work starts when you start testing the integration, or so you think. Another problem is that often you cannot find anyone who knows both systems and have time to test the integration. Often this means that only the happy path is tested before the integration is deployed to production.

That is when all hell breaks loose.

You notice that the happy path is valid for 99% of the use cases but there are always exceptions, and for some reason no one mentioned these when you were implementing the integration. You have to fix those exceptions one by one. It can be frustrating but I have learned to expect it.

You can make your life a lot easier by following these rules:

  1. Never give a fixed prize offer / work estimate for an integration.
  2. Never assume that the original requirements are the only one’s you have to implement. Start digging and ask questions. Try to identify the exceptions before you start the implementation. This makes your code a lot cleaner.

Of course it isn't realistic to expect that these rules will solve all problems related to integrations. Nevertheless, I have found them useful in my daily work.

Second, Assumptions can be dangerous. When I am working on a task, I follow the same steps every time. For some reason I have assumed that everyone else follow the same steps as well. This is of course a bit narcissistic, and last week I noticed that was wrong.

Last week I participated in a session where all developers were divided into groups and each group got the same list of scenarios which they had to solve. It was an educating experience because I noticed that different groups had different solutions for some of the scenarios. When we discussed about the solutions, I realized that I take a lot of things for granted.

That discussion really opened my eyes.

It is obvious that every developer has his own routines which he uses in his daily work.

It is obvious that different persons have different ways to solve problems.

I have no idea how I could be so stupid that I had forgotten these two facts. This experience definitely reminded me the importance of open discussion.

Don’t fall to the same trap than I did. Talk to your team members. Ask if they have any improvement ideas to the way things are done.

If they do, implement them.

Third, It is possible to implement an ajax-like file download. Last week I had to implement a file download function to a single page web application. At first I was pulling my hair out because I had no idea how I could implement this in a clean way. Then I found a jQuery plugin called jQuery.fileDownload.

It is easy to use and has two great features:

  • You can show a popup when the requested file is downloaded.
  • You can handle errors gracefully.

If you are looking for a way to implement a file download function in a web application, I recommend that you use this jQuery plugin.

Fourth, Work estimates are guesses. Every time when I have to give a work estimate for something, the process goes like this:

  1. I read and analyze the requirements.
  2. I attend to a meeting where a team will discuss about the requirements and give work estimates for each requirement.

This seems fairly straightforward. Right?

Let me tell you something. The work estimates are given by using the Stetson-Harrison method.

WE ARE GUESSING!

Does this mean that we have no idea how long it takes to implement a specific requirement?

No. We often have a pretty good idea how big the task is (small, medium, large). That is the best we can do. The funny thing is that customers often want fixed prize offers because they want to reduce the financial risk which they are taking.

Guess what?

THIS WORKS BOTH WAYS!

The subcontractor wants to reduce its risk as well. That is why a fixed prize offer is often more expensive than hour prized pricing.

Is estimating useless? No. The discussions are often very useful.

NOTE: If you want to know more, I recommend that you start by reading this blog post by Neil Killick. It is the first essay in a series of essays so remember to read the rest of the series as well.

Fifth, Technologies are not religions. They are only tools.

The people who know me probably already know that I have a somewhat conservative attitude towards new technologies. I don’t use a new technology just because it is new and cool. I use it only if it can make my life easier.

I am also perfectly aware of the fact that most of my reservations are caused by my personal defence mechanisms. In other words, I want to keep on my comfort zone. Feeling this way is human, but it is important understand that these defence mechanisms might prevent me from making objective decisions.

I have solved this problem by following this rule:

If a programming language (or technology) X feels like crap, I have to try it!

This gives me first hand experience from the technology and helps me to overcome my irrational objections. Of course sometimes I notice that the programming language (or technology) X is crap. That is good too.

This week I read a discussion where developers complained that it is impossible to create a long term career in the software development industry because the lifespan of technologies is too short.

I agree with these people. I agree that if someone wants only to master technology X or the syntax of programming language Y, this person probably shouldn’t write software for a living.

These people should get a real job.

What Did You Learn This Week?

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

2 comments… add one
  • Paulo Aurélio Sep 30, 2013 @ 17:59

    Hi Petri,
    great and useful blog post, i liked it very much!
    Congratulations!!!

    I have read your recent posts and I really appreciated that!!!
    thanks You!

    • Petri Sep 30, 2013 @ 19:28

      Hi Paulo,

      thank you for your kind words. I really appreciate them! Also, it is really nice to hear that my blog has been useful to you.

Leave a Reply