Object Partners Tech Trends
What was asked
Recently we sent out a survey to all of our consultants to get a feel for what technologies are in use across our clients, we dug through the results of that survey to give you a glimpse into the pulse of tech development across the company.
What follows is the results of that survey and brief responses to the results of each question.
1 – The languages currently in use at our clients
2 – The favorite languages of our consultants
What we were going for here is to see what developers actually enjoy writing code in, not necessarily what the primarily language their current client is using. This is good to see as clients or companies who are looking to draw in good talent will want to enable their developers to use the languages that they feel they can be the most productive in.
What we saw coming back on this question was the indication that languages with dynamic features more often make for a more pleasant development experience. We also found a few oldies but goodies such as Java (8), Perl and Python. It goes to show that a language’s age doesn’t always cause it to lose its luster.
3 – Favorite tools to use when building software
This question is good to throw out there so that other people at least have an idea of what libraries they should be looking at to save themselves some time and make for a more productive development experience.
Another trend we see is multiple editors in use by our consultants. This seems to stem from IntelliJ being very helpful at many things, but sometimes it’s huge feature-set gets in the way for certain tasks. This is where we see tools like Microsoft’s VisualStudio Code, Atom, and VIM come in to fill a gap. These lightweight editors are great for quickly opening a file, editing it, giving you enough helpful features such as code completion, syntax highlighting and formatting and fast file navigation.
Another clear up-and-coming winner we see here is Docker. Docker isn’t just for deployment pipelines, but has immense use as a development tool, whether it’s launching a quick data store engine, or spinning up a web management tool it’s a clear winner when it comes to productivity.
4 – What libraries to help you save time and make development more pleasant?
This one drops a lot of big name libraries that if you haven’t heard of them or aren’t already using them deem taking a look. This category hides a lot of gems down in the the less popular responses such as Firebase, Guava, and CodeNarc. These are libraries that are not always as common across clients, but have big gains when brought into use on projects.
5 – What data Storage technologies are you using at your client?
These responses show that despite what many blog posts may try to put forward, RDBMS systems are not dead yet. There are quite a few SQL engines on this list and they don’t have any indication of going away anytime soon. We are however seeing quite a few NoSQL engines pop up as companion engines or supplemental data stores for key areas, such as Cassandra for highly resilient high-write throughput and Elasticsearch for it’s simple and scalable document search capabilities. One of the little guys that has the potential to gain a bit of traction is Firebase which has seen pretty rapid adoption in the mobile arena.
Message Brokers for real-time data processing
This category clearly indicated that RabbitMQ is the easiest entry for clients to bring in a message queuing technology to support real-time data processing, but Kafka quickly comes into play for clients with more data on their message queues. One interesting thing here is that there are quite a few clients that don’t use messaging queues to process real-time data either because they don’t have any experience with it, or there is not yet a business need for it. We mostly see message brokers come into play at clients with larger micro-service deployments or at clients with multiple data centers.
Pain Points encountered at clients
- Lack of CI/CD pipelines that make deployments painful
- Old Technology (ANT, Maven, SVN, SQL Server, JBoss)
- Company Policies that inhibit the use of good tooling (Windows, Maven, SVN, TFS)
- Lack of transparency (Cross team communication, Pull Requests, etc…)
- Fear of Change (often related to the above three points)
- Disorganized documentation that is too far removed from the source of truth
- The desire to “Roll their own” rather than use standard or open source solutions.
This category was difficult to visualize with a word cloud and some topics were unrelated to technology so we’ll steer away from those for now. A common thread seen here is when companies start to fall behind on their technology stacks they find themselves in a position where they can’t migrate to CI/CD pipelines because they can’t support best practices and that position costs them time and money. It is oftentimes difficult to see how the investment of bringing your development process up to the place where you have at least CI if not a full CD pipeline not only makes your developers happier, but it allows you to build a better product at a lower cost on shorter timelines.
The good news for these clients is that we have consultants that are experts in this area and implementing these changes is something that we are very good at. We’ve seen very solid success stories at quite a few of our clients who have moved from slow manual build and deploy processes to full continuous integration and deployment pipelines where they can get a fully tested product to production in minutes to hours instead of days to weeks or months.