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 44.
What I Learned in Week 44
First, Real architecture matters.
The word architecture often creates mental images about complex diagrams which illustrate the architecture of the implemented software. Although these diagrams looks good and professional, they don’t guarantee that the implementation of the application follows the specified architecture. The real architecture is found from the source code.
Maybe that is why developers sometimes say that a software has two architectures: the planned and the real one.
However, you can avoid this situation by taking a good care of the real architecture of your software. It is more important than the planned architecture because if you ignore it, you can end up making mistakes which cost a lot money (and time) during the maintenance phase.
Also, the mistakes made during the development phase can mean that you cannot implement certain features because implementing them would take too much time and money.
Don’t spend to much time drawing those good looking diagrams because sometimes (often?) they have got nothing to do with the reality.
Remember that the architecture is not created in your diagram editor. It is created in your IDE.
Second, Ask for a second opinion.
I have already written about the importance of code reviews, but recently I have realized that sometimes it is wise to ask for a second opinion. I still believe that code reviews done by your team members are important and you should do them on a regular basis.
However, I have noticed that sometimes the code base can make you (and your team members) “blind” to issues which are obvious to other developers. The problem is that when you work with the same code base for a long period of time, it starts to look normal to you. When this happens, it is really easy to start multiplying the “mistakes” found from the code base.
This is of course a mistake but it also a very human thing to do.
The solution for this problem is simple:
You have to ask a developer who doesn’t know the code base to take a look at it. This will give you a second opinion from a developer who is not blind to the oddities of the code base. This way you get valuable feedback which helps you to improve the quality of your code.
Note: This white paper helps you to turn peer code reviews into an agile process.
Third, Embrace your mistakes instead of hiding them.
I have a confession to make:
I make mistakes (even basic ones).
Do I feel bad about this? Of course I do but I also think that mistakes are inevitable. The way I see this is that I have two options:
- I can feel sorry for myself.
- I can move on and figure how to make things right.
I will choose the second option every time.
Also, don’t be afraid that confessing your mistakes will make your colleagues to think that you aren’t a professional.
Everyone makes mistakes.
If someone says that he never makes easy mistakes, he is either lying or he is a some kind of super human.
Which option is more probable?
Fourth, You have a responsibility to make your code easy to maintain.
Most of the developers I know don’t want to maintain software because they think that it sucks. Although some of this resistance is probably related to the fact that these people don’t want to maintain code written by other people, you should still make your code easy to maintain.
The easiest (takes the less amount of time in the long run) way to do this is to write tests for you code. If you don’t want to write unit tests, write integration tests which describe how each function should work. Remember that if your application doesn’t have a comprehensive test suite, the developers who maintain it have to figure out the correct behavior by reading source code and comparing it to the documentation.
This takes a lot of time and money, and is one of the main reasons why software maintenance is considered as a shitty job.
The majority of software’s life cycle costs is consumed by software maintenance. This means that if the code is hard to maintain, the customer has to pay more money to get the same results when compared to a code which is easy to maintain.
Making your code easy to maintain is the best favor you can do for your colleagues and customers.
Just do the right thing. It will do wonders to your reputation too.
Fifth, Processing large data sets with Hibernate is slow if you use regular Hibernate sessions.
This week I noticed that processing large datasets with Hibernate is very slow if I use regular Hibernate sessions. When I profiled the application, I noticed that
- The database query which returned 15000 rows took 45 milliseconds to run.
- It took 20 seconds to build entities from the result set.
I implemented a fix which fetched the results in smaller batches. This weekend I did some research and noticed that replacing regular session with stateless session could help me to improve the performance of this function.
Note: More information about stateless sessions:
I will try this on monday and update the results to this blog post when I know all the details.
What Did You Learn This Week?
Share your learning experiences or other comments on the comment section.