Planning Ahead

Ever since I started working for the new company I have been working on this type of warehouse management system, although we call it ‘material flow control’. Many things have changed since the initial design (which I wasn’t part of), the biggest one being going from a generic to a specific approach. At the moment this decision was made, my team lead also told me to forget about persistency for now and just focus on the functionality.

With all the bare functionalities implemented, it is time to start working on the presistency. This proved to be much harder simply because the design wasn’t made with persistency in mind. So my first priority was to refactor a lot of the code so it can be more easily be stored and recovered from a database. Clearly this could have been avoided and saved a week of effort for the already too tight deadline.

So clearly my team lead likes refactoring, I think he even likes it more than actually writing any code, probably because the refactoring can be done for you most of the part by the IDE. Why else would he have told me to forget about persistency? It is such a major part of any system that goes to the bone that it can not just be added later. So much for just looking ahead, so it amazes me that when I wanted to start working on the persistency he wanted me to come up with a plan before writing any letter of code.

Clearly he wants to plan ahead now, but for what reason? All the code is already there, and now all you have to do is write it to the database and make sure you can recover with the data that is provided. In my opinion creating such a plan is a waste of time, you will spend days on just thinking of every scenario and finding a way to recover from it after which you can finally start coding only to find that there are other scenario’s you didn’t think of or you encounter a problem making your scenario impossible to use.

While I do like thinking ahead, I prefer just taking it step by step. In any high availability system the first step is to make sure you can write the data to a database and read it again to restore the objects as they are. In a lot of cases this will actually be enough to get the required high availability. In this application however there are order being transmitted that need to be followed up upon. As these orders could have progressed during the offline time, it is essential to catch up with them.

You can imagine my team lead wasn’t very happy when he found out that I already wrote a lot of code to write things to the database. But as a Software Engineer I’m getting sick of him constantly looking over my shoulder, telling me how to do things. I am capable of designing and implementing a complex system, the current project I am working on proves it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.