I released five new sample lessons from my Test With Spring course: Introduction to Spock Framework

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

What I Learned in Week 45

First, A good process must make your work easier and/or faster.

I am not a huge fan of the word process because it brings back a lot of bad memories. When I hear this word, I immediately associate it with something that makes my work harder or/and slower.

And yet, I understand that a team can function only if all its members follow the same workflow (I guess you can call this a process).

However, a bad process and a good process have one crucial difference:

Bad processes are invented by managers. Good processes are agreed inside the team.

A good process has one and only one goal: It must make your easier and/or faster. If the current process doesn’t do this, it is broken and it must be fixed. The problem is that if your current process is invented by your managers, you have a zero percent chance to change it anytime soon.

Maybe this why so many companies have two processes: the official process and the way things are really done. This makes no sense.

This is a message to all managers out there:

Let your team decide how they want to do their work. You can (and probably should) specify the goals which must be met, but if you want that your team members are committed to meet these goals, you cannot dictate how the actual work should be done.

Second, Creating reports from the operational database is a terrible idea.

If your reports are so simple that you don’t have to combine data from multiple tables and perform complex calculations, it is often best to fetch the data from the operational database. The problem is that when you have implemented these simple reports, you might have to implement new and more complex reports.

What should you do?

I understand that it can be hard to convince your boss or your client to give you permission to create a separate reporting database. It takes a lot of work because you have design the reporting database, create routines which transform data from the operational database to the reporting database, rewrite the current reports, and implement the new reports.

Nevertheless, it must be done.

Remember that

You might able be implement the required reports against the operational database for a while. However, when the amount of data grows and/or your reports become more complex, generating these reports will be slower and slower.

At some point you face a situation where you have optimized everything, and the reports are still too slow. You realize that the only way to fix this is to create a reporting database.

Do you really want to be in this situation?

Third, Complex user permission scheme is a good idea only on paper.

Real life is full of exceptions. A good way to realize this is to design a user permission scheme for an application. The original requirements might be rather simple but the odds are that when you dig a little deeper, you find a lot of exceptions.

To make matters worse, your client expects that you include these exceptions into the user permission scheme.

Don’t do it!

A complex and flexible user permission looks good on paper but remember that you have to implement it too.

Complex user permission schemes have two problems:

  • They are hard to implement and maintain.
  • No one doesn’t really understand how they work.

In other words, often (but not always) a complex user permission scheme is not worth the trouble. I have one principle:

Software should make things simpler, not harder.

Complex user permission scheme violates that principle. That is why you should avoid it at all costs.

Fourth, Entities are expensive!

Those of you who read my learning diary on a regular basis might remember that I changed my mind about querying entities inside a read-only transaction. I had a hunch that returning DTOs instead of entities would be faster, but I had no idea how much faster it would be.

I was supposed to do some performance testing but I have been too busy (lazy) to actually do it. That is why I was extremely happy when I noticed that Blake Caldwell had created a small benchmark project which proves that querying DTOs is three times faster than querying entities even when the executed query is very simple (no joins).

You might want to read his latest blog post about this subject. The actual benchmark project is explained in this blog post.

Fifth, No matter what is going on in your life, you can always fight back.

This week I was watching a Finnish talk show, and the host invited Pekka Hyysalo to tell his story. He is a Finnish freestyle skier who was on his way to top when he was seriously injured while filming a new skiing video. He suffered a serious brain injure and spent 17 days in a coma. When he woke up, he was unable to eat, speak, or move.

But he didn’t give up. He decided to fight back.

I know that story has got nothing to do with software development, but it reminded me about the fact that most of us take too much for granted.

We assume that we have real problems:

  • We might think that the code base which we maintain is full of spaghetti code.
  • We are pissed off because our colleagues might not want to write unit tests.
  • We belief that our wage is too low.

In reality, none of these problems is a “real” problem, and all of them are relatively easy to solve.

All people are not that lucky!

What Did You Learn This Week?

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

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

4 comments… add one
  • Excellent post!

    I totally agree with your first point, and I always tell others to “Empower the developers, not the process”.

    Reply
    • Thank you for your kind words. I really appreciate them.

      Reply
  • Hi Petri,

    Just to say this post is not under blog menu entry.

    Cheers :-)

    Reply
    • Hmmh. Weird. I just checked this and it was there. Well, maybe the caching plugin had something to do with this. I emptied the cache. Let’s hope that it did the trick.

      Thanks for pointing this problem out!

      Reply

Leave a Comment