Are you a professional?

Well are you?

One thing that frustrates me is implied meanings. If something is to be communicated accurately then use the correct words to describe it. Do not imply meanings in words that are not meant to be used, just because they sound important.

There are two such instances that drive me crazy. One, when people expect certain types of behaviour from a “professional” and then the common “we are all adults”. Lets address the first one shall we?

We are all professionals.

No seriously, if you getting paid to do work, you are a professional. The definition of professional?


1.of, relating to, or connected with a profession. “young professional people”
2.(of a person) engaged in a specified activity as one’s main paid occupation rather than as a pastime. “a professional boxer”

So, are you a professional software developer? Are you a professional architect? Are you a professional driver? If you getting paid to do it, the answer is yes. I saw the list of a “true professional” in this article. While I believe the intentions of the article are to make people better at their jobs, I believe it does more damage than good regarding the definition of a professional.

We are all adults here

I have often heard this used as a means to define how people are expected to behave when interacting with each other. The ironic thing is that adults are the ones that continually do horrible things to each other in business.

1. a person who is fully grown or developed. “children should be accompanied by an adult”

1.(of a person or animal) fully grown or developed. “the adult inhabitants of a country”

Any description of behaviour there? I can’t see any.


You call it dismissive, I call it rude

Often I have heard the saying “it’s not personal, it’s business”. Someone actually posted an article regarding that very statement here “It’s Not Personal. It’s Business”

The statement above often makes me think how certain people justify, what might be classed as rude behaviour, their actions. Often I hear people saying “grow a thicker skin”, pretty much telling people to become jaded and make no emotional investment in what they are doing. After all, they are just resources. I had a small seizure during a discussion with a team of developers I was involved with.

The discussion was regarding whether or not we needed a representation of the expected ethos and behaviour of the members towards one another. The general consensus was “no, we don’t want rules in place to govern our behaviour towards one another. We are all adults (whatever that means) and should behave accordingly”. The team then took a vote and decided the memo or document or what ever you want to call it should contain a few guidelines.

The discussion went on to detail some very fine grain behaviour and no go discussion or joke topics. Being a man who likes to reduce complexity, I made the suggestion that we sum all those things up and say “Treat team members with respect, compassion and consideration”. Again, this set fire to the room and everyone spoke about how they didn’t want rules. At this point the seizure began and, although my body was there, my mind was screaming to get out of the room.

Another issue is this statement doing the rounds “it is easier to ask forgiveness than permission”. What utter hog wash! If you find it easy to say sorry, then you are not. The act of requesting forgiveness requires humiliating one’s self. To throw yourself at the mercy of the individual you are seeking forgiveness from. I find it ironic that, in South Africa, we moan and complain about government, saying they don’t care, yet we don’t look at our behaviour and condemn ourselves for the way we don’t care. I was taught from a very young age to consider the state of my house before judging another man’s house. If you say sorry, mean it.

Get on with it will you?

Anyways, moving on. Something I have recently observed is a behaviour that seems prevalent in most large companies. Some people call this behaviour “being dismissive”. I sum it up as being rude.The corporate world has rewarded those who scream the loudest and drown out the voices that might have something valuable to offer. If someone raises a point and the response to it is “yes, good point” and the conversation topic changes to something else or doesn’t even consider the comment just made, the people engaged in the conversation are being rude.

My favourite part about this behaviour is when something goes wrong, the first comment is “why didn’t anyone point that out?!”. To which someone is saying to themselves, “I did point it out”. The wheels come off, fingers start pointing and everyone runs around in a flat panic.

It is absolutely imperative that everyone on a project be heard. Do not dismiss the statements made by people perceived to be juniors. Listen to the guy who barely talks. Understand what is being said to you. To often, we let the person finish speaking, acknowledge the fact that he is done and simply forget what was said.

So if we move away from the project aspect of it all and just consider for a moment how this makes people feel. Personally I am tired of being surrounded by cut throat attitudes. Business is personal, it has to be, it involves other people! If you want to extract the best from someone, if you truly want them to excel at what they are doing, invest your time in them. If you nurture a relationship with the members of a company or team, you foster trust. Once people start trusting each other, getting things done becomes easier. Creating an environment of distrust leads to the opposite, an environment of people constantly looking over their shoulders. They spend so much time looking over their shoulders that nothing gets done.

In short – work with people like they are people, everyone wants their dignity and to be treated like they have a place in what ever is being targeted. Forget about the “if you want it done right, do it yourself” mentality. We all need to put our own selfish agendas and desires aside and look to aide our neighbours, friends, family and work colleagues. Then we can all take the masks off and live a simpler life.

ERROR: relation “hibernate_sequence” does not exist

Recently while working on a Spring Boot project, I grabbed a fresh copy of the source from our GIT repository. After importing the Maven project I attempted to run the test suite attached to the code base. The unit tests ran fine but as soon as it hit the portion of code responsible for testing the integration with the RDMBS, which is Postgresql, I was met with the following error:

org.postgresql.util.PSQLException: ERROR: relation “hibernate_sequence” does not exist

After a bit of investigation into the code that was attempting to run, it appeared that the issue was coming from an annotation. The following line attached to the Id was the culprit:

@GeneratedValue(strategy = GenerationType.AUTO)

After a little more digging, it became apparent that the database had initially been set up manually and this sequence had been generated during the creation of tables. When Hibernate was tasked with creating the tables in a fresh database, it couldn’t seem to find what it was looking for.

To resolve the issue, simply changing the annotation value got it returning the expected behaviour:

@GeneratedValue(strategy = GenerationType.IDENTITY)

While looking at this, it became apparent that we needed to start doing two things:

  1. Rely less on Hibernate to create the tables
  2. Perform the integration tests against multiple database vendors to verify that we have met our mandated condition to make the application vendor agnostic.



Does Agile need senior management buy in?

Agile has become a major buzz word being thrown around in the meeting and board rooms. It is often assumed that because the development effort has been mandated to follow an Agile methodology the project will take less time. The problem comes when the project is not allowed to follow an Agile methodology. Management gets disturbed when progress is not apparent and starts requesting large amounts of documentation. The development effort grinds to a halt while this documentation is produced. What happens next is a rather nasty mix of Waterfall with Agile expectations. We will call this Wagile.

The problem

For anyone familiar with Agile and the scenario described above, you have probably already identified the problem. One of the 12 principles of Agile software speaks to trust.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

When documentation or proof of progress via paperwork is required, alarm bells should be going off regarding the trust the requester has in the team tasked with producing the work. While I agree that some form of up front thinking is needed before embarking on a development effort, requesting documentation that the up front thinking is being done seems to be a waste of valuable time. We need to ask ourselves why this documentation is being requested.

Why is the documentation being requested?

Going back to the principle of trust we have to first understand the concept of trust. The term is thrown around rather loosely nowadays and holds very little value. A quick “define trust” search on Google gives us the following definition:

“firm belief in the reliability, truth, ability, or strength of someone or something”

This firm belief is not something that comes easily, especially when millions are being poured into the project. Especially in large corporate environments where the stakeholders funding the project are not involved in the day to day operations of the team. Small start-up companies have a distinct advantage in this space because a flat organizational structure means it is easier to include the stakeholders funding the effort. With this reasoning, it is pretty easy to see why the documentation is being requested. The stakeholders funding the project do not see the work being done and the progress being made. This lack of visibility leads to a feeling of distrust that work is not being done yet people are getting paid.

How do we negate this distrust?

The easiest way to fix the problem described above is to increase the visibility on the work being done. There are many different ideas on how to do this but the primary point is that it has to be easily accessible to the relevant stakeholders. Once the stakeholders have complete transparency on the work being undertaken, they tend to understand the problems the team is facing and are far more inclined to introduce means to help mitigate any impediments preventing the development team from succeeding. This is why it is imperative to follow another principle of the Agile manifesto:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

People with a hand in the project need to be easily reachable. They should engage each other regularly. If a question is raised, an attempt to should be made to resolve it immediately via a conversation with the party that might have the answer. If a decision is made it should be communicated to everyone that needs to know about it. This is were things become tricky.

Increasing visibility

Often, as technology professionals, the first thing we want to do to solve a problem is introduce a system. Task tracking, time tracking and the list goes on. Everything has to be logged into a system, carefully recorded for auditing purposes to prevent any recourse if something goes wrong. The underlying thought is one of “if this doesn’t work out, at least I have myself covered”. The problem with introducing these systems off the bat is it violates the Agile manifesto, namely:

“Individuals and interactions over processes and tools”

If any teams is just starting out down the Agile road after being heavily involved in Waterfall development, introducing tools and processes increases the risk of everything being molded into a Wagile process. While the tools say “Agile” the underlying process is very much Waterfall. One thing people find very hard to let go of is the investment they have made in learning things. The one way to get people to let go is to introduce a mechanism that is completely contrary to what they are used to.

Having coached a few teams in Scrum, the initial resistance is generally dropped when people start interacting with the methodology. For some reason, the act of moving a physical sticky note from one column to another leaves the individual with a sense of accomplishment. The side effect of moving the sticky note also leaves a status update that anyone can view without having to request status documents. This visibility increases trust and teams are not weighed down by the burden of evidence proving they are working.

Once the team is more mature and have established a means of organizing themselves, tools can be introduced to replace manual means in use. The reason manual means are better initially is because while you are establishing how your team will work, the process might go through multiple iterations. Software tools have a habit of being very difficult to easily reconfigure once the process has been set up.

Another means of increasing transparency is the demonstration of working software. This speaks to a few processes in the Agile manifesto:

“Working software is the primary measure of progress.”

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

The demonstration of this software on a regular basis shows the relevant stakeholders that software is being built. So as opposed to pumping money into something for month and seeing nothing, people get to interact with software and see additional features being added continually.

How does senior management fit in?

In large corporate environments (the context of this article) senior management is often difficult to get hold of on a regular basis. Often the feeling portrayed to development teams is that they have far more important things to do and keep up to speed with the progress of development.

While it cannot be expected that they will attend daily stand ups, view boards depicting progress or log into software tracking progress, they should attend the demonstrations of the working software or at the very least, have access to the working software. The demonstration would be first prize due to fact that contextual questions can be answered face to face. This will also help establish a stronger feeling of trust in the development team.

In closing, Agile does not work unless the entire organization buys into the effort. It is imperative to have everyone involved from the beginning. It does not work if teams go off and collect requirements then flush those requirements down to development teams and wash their hands. Inevitably development teams will push the requirements back to the requirements team who will have to reschedule time to answer the questions and potentially go through another requirements gathering exercise. By the time the requirements are solidified, the business has changed its requirements and the delivered software no longer meets the immediate requirements the business has.

Business people and developers must work together daily throughout the project.”

All hands on deck!


  1. The Agile Manifesto
  2. 12 Principles of Agile software
  3. Definition of trust