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 36.
What I Learned in Week 36
First, A Product Owner cannot function without the authority to make decisions. Wikipedia defines the Product Owner as follows:
The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring the team delivers value to the business.
When you have a question about the product, who is the person you go to? Exactly. You go to talk to the product owner and expect him to have an answer to your question. If there are decisions to be made, you expect him to make them. Right?
If the Product Owner has to confirm his decisions from someone else, why should you talk to him?
If his decisions are revoked later on, why should you trust his decisions?
The problem of having a Product Owner who has no authority is that the team cannot rely on the Product Owner to make decisions. To make matters worse, the team cannot trust his decisions.
Do you think that this could work on a long term? I don't.
Second, Learning a new way to do things doesn't mean that you should use it in every situation. A few weeks ago I ran into a pattern called the test data builder. The idea of this pattern is to
- Hide the construction logic of new objects behind the API of the test data builder class.
- Create a DSL which communicates the business value of the objects created in our tests.
Since this is a really cool concept and it has a huge positive impact to the readability of my tests, I got REALLY EXCITED about this, and started using it everywhere. I created test data builders for every object I used in my tests.
After all, if the concept is so cool, why shouldn't I use it?
It took a couple of weeks for me to notice that there are situations when using test data builders leads to over engineering. I had forgotten that the most fundamental goal of this concept is to make things simpler.
I realized that when I was busy writing all those test data builders, I was coding on autopilot. I remember a few situations when I fel that creating a test data builder doesn't make things simpler. I ignored that feeling. It was a mistake.
It does not matter how cool this new pattern/technique/programming language is. You are the one who have to decide when it makes sense to use it.
Do not make the same mistake than I did and ignore your gut feeling. Listen to it.
Third, SQL is back in fashion. I ran into a library called jOOQ. The website of the library states that
JOOQ is a fluent API for typesafe SQL query construction and execution
Its API looks very good and fun to use. If you want to use SQL in your Java project, you should definitely do yourself a favor and take a look at jOOQ.
However, jOOQ cannot replace the traditional ORM tools in every application. What it can do is to offer a different way to implement data access layers.
Traditional ORM tools concentrate on the domain model of the application, and see the relational database as a necessary evil. This approach works very well on domain-driven applications.
jOOQ flips this around. It concentrates to the relational data model and embraces SQL. There are situations when using a tool like this makes a perfect sense.
For example, let's assume that you have to create a complex reports from a data stored to a relational database, and you have to do it by using Java.
The problem of traditional ORM tools is that optimizing complex queries is not exactly a walk in the park. That is why these tools are not a good fit to this situation.
How about jOOQ? It seems like an interesting option but since I have not use it myself, it is hard to know for sure. However, it would be interesting to find it out.
Fourth, The most fundamental goal of a quickstart project template is to help you get started as soon as possible. If it is easier to create a new project from scratch than use a quickstart project template, the template has no value at all.
This seems obvious but the problem of "enterprise developers" is that we tend to over engineer everything. This includes project templates as well. When we are finally pleased with the outcome, the template might be so complex that it is impossible to understand what it does without spending a lot of time to figuring it out.
A project template like this might be an excellent proof of the engineering skills of the persons who created it. This is often an admirable achievement.
Nevertheless, the sad fact is that if it doesn't make my life easier, it is worth nothing to me.
If you are creating quickstart templates, you should follow these three rules:
- Make things simpler. Not harder.
- Ensure that it is possible to update to newer versions of libraries and frameworks without breaking everything.
- If your project template requires an user's manual, it is too complicated.
Fifth, Gathering data is not enough if we do not use it. I started reading Buyology by Martin Lindstrom and found the following sentence in its foreword:
The problem is that we are getting better at collecting data than doing anything with it.
Reading this sentence had a phenomenal effect on me. I like statistics. I have a natural tendency to collect a lot of data which I might need later. The problem is that I use only a smal portion of the data which I collect.
The good thing about this is that I still have the data. All I have to do is to start using it.
I know what to do with code coverage data and I use it on a regular basis. My weakness is that even though I like collecting data about the users of my application, I have no idea what to do with it.
I know that this data is valuable but I have to figure out how I can use it. Any ideas?
What Did You Learn This Week?
Share your learning experiences or other comments on the comment section.