Clients expect engineers not only to deliver performant, maintainable code. Best software developers make decisions with business growth in mind. Thanks to that, return on investment can be maximized, costs minimized and engineers can be proud of the solutions they deliver.

It's not enough to implement features. In this post you'll find out what engineers should do to help business grow.

Discussing idea and gathering requirements

Clients should involve engineers in discussions when they have new feature ideas. It’s a stage when it’s easiest to introduce changes and avoid costly implementations.

Suggesting alternative solution

Quite often Clients will describe an idea for a solution to a problem they have. However, quite often, the idea is overly complicated.

Validating an idea is usually the role of a Business Analyst. But developers should still be critical of ideas. This is because they have knowledge of technical aspects that may make a suggested solution complicated.

When discussing the idea with clients, engineers and BAs should approach it with curiosity and critical thinking. This will help with uncovering the underlying problem that the feature is intended to solve.

Curiosity, from my experience, is not a problem in IT. It's what brings people here.

Critical thinking, or assertiveness, is something that is gained through experience. That’s why it’s senior developers' role to analyze an idea and say that the problem should be solved in another way.

Uncovering and discussing the core problem is a skill and, like any skill, can be learnt. Starting with asking open-ended questions is good, but if the problem or feature is more complex it’s not enough. Business Analysts and developers should be capable of leading the conversation with a client - structuring the discussion and asking the right questions. There’s a reason why conversations with domain experts are so important in Eric Evans’ “Domain Driven Design” book.

If you want to get skilled at discussing problems with clients, I encourage you to read a book by Michal Bartyzel “Conversation Patterns for Software Professionals” (or “Oprogramowanie szyte na miarę” if you know Polish; it’s a bit extended version of the English book).

Cutting on scope

What’s important to understand is that the client wants to validate the solution and get the major benefits ASAP. After leading the conversation with the client BA and engineers should easily realize what functionality subset will deliver the most benefits in the shortest time.

In my project we often implement the mobile-app facing features but delay or skip developing management of those in CMS. It’s the easiest division for us.

What can be challenging is communicating the scope cuts to the client. It's hard especially when the client insists on prioritizing non-core parts of a feature.

I need to confess that quite recently I failed at challenging the client. Because of that, my team spent a few weeks on changes that the client eventually acknowledged should have had a lower priority. What I missed was clearly showing the benefits the core functionality already delivered.

Implementation analysis and planning

After the client, BA and engineers agree on the scope it’s time for developers to choose the technical solutions and plan the implementation so that the costs and potential risks are minimized and benefits maximized.

Presenting limitations and solutions

Not long ago we were analyzing an upcoming feature which relied on integration with 3rd party services. We realized that quite big delays may be introduced by those external partners. They were caused by the nature of their services and the way they were used by users.

What I did was prepare a simple diagram that showed the impact of those limitations on the feature and users. That seems easy but I noticed that developers tend to use technical language when talking with clients. That makes discussions longer and results in clients misunderstanding the message.

Business oriented engineers also propose solutions to minimize their impact. That requires being aware of the goals of the feature to be implemented which brings us back to asking the right questions. Communicating different solutions can be challenging when solutions are quite technical. But in most cases it’s possible to show how different options impact:

• time to implement the feature,

• code maintainability (that includes scalability and resiliency),

• user experience.

Incremental implementation and gradual deployment

It’s the last stage so introducing changes is harder than in the previous ones. Yet, engineers can still use some techniques to maximize business benefits.

There are 2 general tools:

• planning gradual deployment,

• incremental implementation,

It’s important to note that the 1st one can make the 2nd much easier to plan and execute.

Gradual deployment

In the feature my team is working on right now we decided that it’d be good to release it to the users gradually. The advantages of such approach are:

• gathering initial feedback about the solution,

• have only part of the users impacted by potential bugs and,

• buy us some time to make our code properly scalable (what I like most).

A/B and canary releases are already quite popular which means there are tools that make it easier. Our project uses Firebase for deciding whether a user should see the new feature or not.

Incremental implementation

In Scrum the common way of working with big features is splitting them into smaller parts and implementing them one by one. That’s good for knowing the actual progress of the functionality development. Engineers should be able to find technical solutions for features to bring benefits ASAP.

This can be very challenging when the requested feature is totally different from all the other ones. Quite often this requires use of new frameworks, tools or architectural approaches. But it doesn’t need to delay bringing benefits of the new functionality.

Engineers should analyze whether the feature can be implemented in stages/incrementally. Initial stage should deliver working functionality that users can already take advantage of. This stage can compromise on resources usage efficiency, scalability or other factors depending on the functionality and technical solutions. While it’s already working the next stages can be developed and delivered.

What we lately developed in my team is fetching data from the external service via a periodic task. Implementing it that way has several drawbacks, such as wasting resources for sending requests that return no new data. But the big advantage is that we were able to deliver it fast. The next step is to create a new service which exposes a webhook for the external service to push data to. We decided to have it as a second stage of the implementation because this approach requires us to solve problems related to distributed programming and new kubernetes deployment setup, which we don’t have experience with.

As you can see, when planning the implementation engineers should take into account not only the technical solutions optimal for the feature but also their skillset and its impact on risks.

There are 2 main challenges with this approach:

• Developers need to make peace with the idea that playing with new, exciting solutions will be delayed,

• Clients need to reserve engineers’ capacity for the later stages of implementation. Abandoning subsequent phases delivery poses risks. That requires developers to properly communicate the hazards.

Communicate, communicate, communicate…

As you can see engineers have a big role in minimizing costs and maximizing benefits. It’s important for developers to have proper attitude and communication skills. That’s why I encourage you to develop yourself and your team in this area. Pay also attention to what you can improve in the business oriented approach.