Oct 12, 2017 | I learned | 0 comments

Here I was, writing code as I do on a daily basis when a horde of requirements struck me so hard that almost knock me out. The requirements were fairly simple at first sight.

Our users wanted every field on the website validated as they were filling them, showing a message if they were not valid. But here is the thing, that page worked like an invoice would do. You set some fields that are part of the invoice, then add lines of products and finally you save them. They wanted the fields that formed each line to be validated when they were added, but they had to be added automatically when they were filled, along with some other requirements that needed further interaction.

How come so simple requirements felt so hard? Here is the deal: in my organization, we are a java team. We use wicket to help us solve user interaction and all the UX is wicket based. Since this awesome framework has ajax integrated in a way it is incredibly easy to use and allows you to use HTML and JS as much as you like, solving the requirements may seem an easy task. But that is not the problem; the problem is we are a java team.

We are specialized in java development, specifically in server side technology. Not in JS development nor any client side technology. By being a front-end lover, I like giving the user the best experience possible. At the same time, the code we write, as developers, should be maintainable by any other developer. What should we do? It is clear the requirements are best solved by using a client-side technology. Should we have another team for these requirements? Should we use client-side technologies that not all developers know how to use?

I think, this is why general knowledge of technology is not only useful, but a requirement. Knowing more than just a specialty is a proof that you can adapt for this kind of situations, which are not that unlikely to happen. So, what if we are all generalists, but we just don’t share the technology that best fits the problem? That is when knowledge sharing becomes important. It should be important to share at least basic, functional knowledge, in those technologies that are not the core of the team. That way, when any of them becomes relevant, the team can use it with enough confidence to be able to maintain it.

Of course, all this may seem irrelevant if you have multiple specialized teams (although I could argue it may be useful anyways), but that is not always the case. I just want to point out that sometimes specialized software development is not that specialized. In these cases, it is important to have a strong knowledge sharing culture. And of course, a complementary team covering all aspects of software development.