Nowadays, many companies pride themselves on having an excellent workplace and company culture that lets their employees thrive. For some people, it has become a significant factor in choosing their next job, as they look for an organisation that respects and shares their values.
As a software development company, Evojam provides services to external businesses. We believe that shared team values are the core of employee satisfaction and successful collaboration with our colleagues and clients. The success of any software development project relies heavily on the cohesion and alignment of our values. Possessing technical expertise is not enough.
Our views on core company values and culture differed due to our diverse backgrounds. However, working in a team requires sharing values and principles. In addition to fostering a positive work environment, team values facilitate collaboration and cooperation between members, allowing mutual understanding and guiding decision-making.
Some of us needed help understanding how Evojam approaches values in our daily work towards our clients and team members. This drove our urge for transparency in company culture and values. We didn’t want them to be just a buzzword; instead, we aimed for something we all believed in.
So, what did we do?
Recently, we have been looking for a new backend developer to join Evojam. I take an active part in the recruitment process, especially in job interviews. What I like best about the interviews is the part where candidates ask their questions.
One of them got me to write this post — “What is your most complex project right now?”
“Well, it depends on what you mean by complex,” we said at first. Then, we did our best to give a meaningful answer, which was rather based on project scale.
But what is software complexity?
Developing a new product can be a nerve-racking experience. It’s an intense time, in which you take thousands of key decisions and look at your solution from all the possible angles.
You’ve put so much thought into the process, it’s only natural that you want the launched app to be the final version.
Then, the market landscape changes, your customer base grows, you update your business approach to meet the current needs of your clients… Your business evolves, but your product stays behind.
What can you do to develop software that will serve you well now and in the future?
Three words — make it scalable.
The early days of a new software project can be challenging.
There are a gazillion things to think of, and deciding where to start is a nerve-wracking moment.
No wonder you want to get past this phase as quickly as humanly possible.
Turns out it doesn’t get that much better towards the end either — applying application code changes requires a fair amount of time too.
Here are four simple steps to get around these bottlenecks and improve your software delivery performance.
As developers, we produce tons of code each day. We test our code, beautify it with code style scripts and finally verify using continuous integration commands, which control the integrity and cohesion of our solutions. Nevertheless, the true value of used code solution can be checked only by another developer, who knows the business domain, best practices, clean code principles and who may also have a different point of view from yours. In this article, I want to show you how code review can help you keep codebase in order and get more advantages for your team.
The software is eating up the world and we all have to face it. This fact drives more and more companies to outsource the IT work. However, finding a right tech-partner or a software house may turn out to be a path dotted with potholes and traps. Why is it so hard to track down a reliable IT partner to build an application? What do we need to consider? Let’s find out!
Imagine your team has done everything that was required. They’re happy. At the same time the client is angry because the work is incomplete. Say “hi” to poor, assumed or undefined definition of done - source of many miserable failures.
Client demo is so damn important that it’s hard to overstate it! Not presenting working software is a brilliant way to pile up problems in the project. Yet plenty of its benefits are subtle and easy to overlook. Do your project a favor and know what’s to gain or loose here.
Sprint scope changes are one of the most common ways Scrum goes sideways. “We have sprints, but… we change their scope.” The paradox of keeping a sprint scope fixed is to welcome change!
Project estimates are extremely difficult and important. Clients need ones they can rely on. They put them on their roadmaps. They make promises to their stakeholders based on the estimates. They budget according to them. There's always a pressure for the estimates to be low (cheap), yet accurate. At the same time we never have enough information about the project. This is the crux of every project. That's the intersection of plans, expectations, priorities, assumptions and uncertainties. How do you handle all that?
