You Don’t Have To Pick Sides

After reading this article, then this article and for some strange reason I indulged myself by reading the comments section, I can only come to the conclusion that we need to take a long hard look at the way we think.

For some reason, people (software developer or not) have this inane desire to be right. You are either right or you are wrong. The occasions that someone turns around and says "the context should guide us to make the decision on what to use to solve the problem" are so few and far between that I shed a tear of joy when I hear someone hint at it.

There is no silver bullet, only in werewolf movies. It is imperative that we investigate continually, challenging our own perception of things. We should have as many tools in our bag of tricks as possible. One architectural pattern solves problems in a specific context. The other set of patterns solves problems in another context and perhaps a mixture of architectural patterns solves the same problem in an unseen context.

We need to start thinking again and stop just being parts fitters. One size does not fit all. We need to go back to the days when we crafted the components of the system, leveraging of hard earned experience and leaning on the experience and work of our peers. We need to stop trying to be movie / rock stars or ninjas or some other form of celebrity.

Stop the bickering and name calling. We need to stop taking ourselves so seriously and have some fun with what we do again. After all, it all started with the Lego.

Email Validator

Often I need to validate emails so I go online and figure out the regex needed in order to validate it. Recently I came across a class from Microsoft –

As we all do, I figured I could do a better job and refactored it into this:

public class EmailValidator
    public bool IsValid(string emailAddress)
        if (string.IsNullOrEmpty(emailAddress))
            return false;

            emailAddress = Regex.Replace(emailAddress, @"(@)(.+)$", DomainMapper,
                                  RegexOptions.None, TimeSpan.FromMilliseconds(200));

            return Regex.IsMatch(emailAddress,
                  @"^(?("")("".+?(?<!\\)""@)|(([0-9a-z]((\.(?!\.))|[-!#\$%&'\*\+/=\?\^`\{\}\|~\w])*)(?<=[0-9a-z])@))" +
                  RegexOptions.IgnoreCase, TimeSpan.FromMilliseconds(250));
        catch (RegexMatchTimeoutException)
            return false;
        catch (ArgumentException)
            return false;

    private static string DomainMapper(Match match)
        IdnMapping idn = new IdnMapping();
        var domainName = match.Groups[2].Value;
        domainName = idn.GetAscii(domainName);
        return match.Groups[1].Value + domainName;

A family without a country

With the recent madness around the removal and destruction of statues depicting South African history, I have been very sensitive to comments made about white colonialist and white supremacy. Further to that, comments made in the media by Robert Mugabe “I don’t want to see a white face” and another by some professor at the University of Cape Town along the lines of “the people in South Africa take the peace for granted”. All of this had me thinking but a light went on when watching a “heritage” piece by the South African TV show Carte Blanche.

It was a piece about the Bokoni people but that is irrelevant. What is relevant is the use of the term “Africans” to describe the natives, before the colonialists. There in is the problem. While it seems to be a relatively “politically” correct description, the implications are far reaching and explain the divide that is being made bigger by all the talk of white supremacy and the eradication of it. Unfortunately, to get the point across clearly, I am going to have to describe ethnicity by colour, nothing personal.

The term “African” is often understood to be a native of the continent before colonialism. Why is it different in Africa? If one is born in Europe they are said to be European, without any attachment to ethnicity. Someone born in North America is said to be American, again without any attachment to ethnicity. The examples go on and on. For some reason, someone born in South Africa is not regarded as African. Why is that? If you are a citizen of an African state, why are you not classed as African?

I cannot be European, I need visas and permits to visit European countries, I am not Canadian, North American or Australian – my passport says I am a citizen of South Africa. If I was any of these things I would be able to go home without needing special permissions and documentation. I cannot get into my “home” land because my home land is South Africa. Surely, because of this I am African? If I am not African, or any other nationality, what am I? If I have no country, what do I leave to my children? What country do they belong in? Extremists in South Africa would have us believe we belong in Europe with our fore-fathers (many, many, many generations ago this might have been the case but no longer). I cannot go “home” to Europe, they won’t have me unless I get special documentation giving me temporary admission.

I cannot go home to North America, South America or the Middle East. I cannot go home. So we live in a country that we believe is our home but constantly face the threat of forcefully being expelled or killed in. Our home is one built on the fear of never actually belonging in it.

Perhaps this is the reason so few people stand up and fight against what I have just pointed out. Perhaps we figure that staying quiet and going about our business, as law abiding citizens, will let us fly under the radar. So if anyone has any idea where white South African’s can call home, please let me know. For now, we live as families that have no home land.


Don’t get me wrong.

Recently I received an email and it went a little something like this:

This article makes a compelling case for Enterprise Architects as active participants in sprints and as close partners to developers:

Some of the points I got from the article:

As part of the development team, architects primarily act as customers

In the traditional setup, an “us versus them” attitude often exists between the architecture team and the rest of the development organization

By working together, the architects and developers can begin to appreciate their respective objectives and openly deal with conflicts when they arise.

I didn’t see anything that mentioned joining sprints. This articles speaks to the involvement from all personnel in the system delivery effort. This is a Lean principle “all hands on deck” and it advocates the inclusion of everyone right from the beginning. Enterprise Architects are not called to be involved in the physical implementation of the system but to “act primarily as customers”. This means handing down requirements and helping decided on the priority of the requirements.

I often think that the term “Enterprise Architect” is misunderstood as the “super duper technical lead”. Expecting an “Enterprise Architect” to actively engage in the development cycle and the business cycle is unrealistic. Enterprise Architects would engage at the same level as the Product Owner. Due to the diverse nature of Enterprise Architecture, technology lag can be created and having an EA trying to ramp up during development will cause more annoyance than benefit, especially when certain teams are focused on one technology and other teams are focused on a completely different technology. This is made quiet clear with the statement:

The architecture team must have a much broader perspective, because it must balance a particular application’s needs against those of the entire enterprise portfolio.

“This level of cooperation requires the same kind of resource commitment as that expected from business users.” – this is a key point.

The article is a little frustrating in that it talks about “Enterprise architects” and then uses the generic term “architect”. Each architecture discipline requires a different skill set and level of commitment. The Enterprise Architect is probably the furthest from the development effort in terms of commitment to time spent implementing, with the solution architect and software/application architect progressively getting closer to being actively involved in the development effort.

(This is not a rant on the content of the literature previous provided, just a note regarding the fact that the definitions of architecture roles has been changing over the years with other architecture roles introduced to fill the gaps.) The article is dated 2005 and “what” an enterprise architect is has changed significantly since then. A more up to date article is probably required.

A pretty accurate and slightly less dated article:


We also need to bear in mind that “Agile” is a concept and “Scrum” is an agile project management discipline. Too often we think because we are using “scrum” we are agile. The only way to measure if you are agile (according to the definition produced by the term’s founders” you subscribe to:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

This applies at all levels of the effort: architecture, analysis, requirements gathering, implementation. The primary driving force behind agile is trust. A group of people does not a team make – even if they are trying to deliver the same thing.

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