Developer Teams Must Work Differently in the Future

As we inject more new technology into our everyday lives, software development continues to be one of the most popular and fastest growing job fields. But have you ever really thought about the core essence of a developer’s work?

Software developers tend to think and work only inside the tasks they are assigned to. If they are to write a code on a specific project, they only work on the coding process. As the CEO of a software development company that has been in the industry for more than a decade, I believe that this attitude from developers results only in the loss of career growth. Why do we call them “developers”? Why not “coders” or “programmers”? Because the word develop implies that you are helping something to grow. Developers are supposed to help the whole project move forward and succeed, not just write a code and let it go.

Take a look at this average software development workflow:

Requirements -> Design (UX/UI/Graphic) -> Coding -> Testing -> Deployment -> Support

Developers must feel responsible for the successful execution of each step of the workflow. The overall success of their code depends on it. When they put themselves solely in the coding “box,” the quality of their work becomes invisible. It may look like they did a great job even if as a team they failed to deliver the solution the company needed.

Teaching developers to question

Developing a product means talking to your team members, asking BAs and designers questions to see if they have understood the customer well enough to start coding. You need to talk to QA specialists and deployment and support teams as often as you can to make sure they take on the workflow in the right way.

Learning to question can be pictured with this analogy: Let’s say someone asks you to bring them a cup of water. What do you do? An aware developer will ask, “How is this water going to be used?” If you need it for drinking, it will be brought to you clean and fresh at a cool temperature. If you need it to water a plant, it will be brought to you at room temperature and probably not even in a cup. If you want it to make some ice, perhaps there’s some ice already made and it can be brought to you directly.

Knowing who, how, when, and why the system is used allows developers to make the code resilient to changes and come up with innovative ideas to make the system more robust and efficient.

Some people may argue that this kind of developer work cycle may be urgent only in small or mid-size companies, but I don’t adhere to this opinion. Even in large companies developers need to be aware of the whole work process of the team and the project. Only in this way can the development team succeed and enjoy the good feedback and flow of gratitude from their customers.

Eliminate silos, eliminate errors

There was one project we had where QA teams had automation scripts and developers kept changing the UI elements in a way that continually broke the automation. As a result, QA took longer to find and report issues to the developers, sometimes lagging behind by as much as month. Fixing a bug on a month old code is unpleasant, and bears the overhead of merging it back into the current code base. To solve this, we implemented a naming pattern for UI elements so that the QA team could create automation scripts using that pattern and add logic with parameters. We also started to help QA update their scripts if they were too behind in order to push our code through QA sign-off faster. This eliminated the need for old code bug fixes and nasty merges.

The app lifecycle is everyone’s job

Ultimately, developers have to understand and take responsibility for the lifecycle of a developing product. After product deployment, the customer will either curse you or bless you. You: the developer! Not the designers, business analysts, or QA engineers, regardless of whether the project and collaboration suffered due to those teams. As the person responsible for the overall project, the customer sees only the developer.

As a CEO, I find that reminding this basic fact to Margasoft developers from time to time is one of the keys to the growing success of our company. At Margasoft, developers share the problems of their team members while working together to find solutions. They think as one team. They step up and take responsibility.

People over product

I always like to tell my employees that they develop customers’ lives, not just code. We tell them the customers’ stories and show them their pain. The number of working hours and lines of codes don’t matter to me if the developer doesn’t pay attention to the end result: the product, the cornerstone of the change in someone’s life. When possible, I invite the developers to user demos so they can hear feedback directly from the customer. It helps with motivation to see and hear the person who will be using the end product. Extra effort is rewarded, both with bonuses and sincere gratitude from end-users.

If you want to be important to your company as a developer, you must put yourself in the shoes of your customers, managers, BAs, and designers before you write your first line of code. Every line of code must be connected with a customer need. If you don’t know the essence of the task then ask the right questions. This will enable you to work as a real engineer, a creative thinker, and a truly responsible team member.

Armen Margaryan is the CEO of Margasoft Corp, a software development company that has been around for more than a decade. Armen is an engineer at heart who loves setting high goals and enjoying the success of reaching them. He is passionate about working with clever, intelligent, and creative-minded people, and likes seeing the impact of his ideas on clients.

Connect with Armen on:  LinkedIn

Author

Alexandra

More articles by Alexandra