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.
- The operational database is normalized to minimize redundancy.
- The reporting database is denormalized to provide the best performance for reporting.
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).
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.