If there is one truth I have come across software development, it is that there are never enough software engineers in the market. Hiring for software engineers is an always ongoing process in each and every company. Recruiters always struggle to match the demands (of hiring). In the last 20 years, hiring for Software Engineers has been a sellers market.
Yet I am never amazed by how little we have done as an industry to optimise the output of the engineers we have, and to minimise the waste, both in time and resources.
For the purposes of this article, Waste is any activity that doesn’t produce business value.
After having worked in over 8 companies, both in India and in Europe, I have seen very little consistency in how we work and what we do to maximise developer productivity.
Below I am listing down different ways people waste time and resources while building software. I write ‘people’ instead of ‘software developers’ because the process of developing software involves a myriads of non-tech people involved. They include the engineering and product leadership, the business executives, and so on.
Building the Wrong Feature
The worst kind of waste is to build something the user doesn’t need. Yes, it is so simple, and yet it happens everywhere. There are three reasons for it :-
- Lack of Feedback from Important Stakeholders – These stakeholders include people who have to sell the product (sales), who have to interact with the customer (customer service), who have to approve or can veto new features (legal and leadership teams). A feedback loop involving stakeholders should be in place before, during and after building a new product feature as they are closest to the customer and can often provide inputs preventing repeat work & time wastage.
- Lack of Homework – This happens when not enough user surveys, research and focus groups are done to understand what the user needs. Stepping into the shoes of the users, and hearing directly from them is the easiest way to understand their pain points and challenges. Yet many product managers directly jump into building features, either based on their intuition or due to the wishes of senior leaders.
- Not A/B Testing Soon Enough – It is really hard to figure out what the user wants. Even with all the feedback and user research, it is often only after an A/B experimentation that you know if your idea works or not. Hence waiting too long to do an initial A/B experiment is another way precious developer time is often wasted.
Redoing Code Which You Just Delivered
Very often software developers end up redoing code they just delivered. This usually happens because of ambiguous requirements and lack of clarity in the first place.
Often new business information gets available which was not available before. It is also common to redo code because the initial implementation lacked in quality due to prevailing tech debt in the organisation.
Over Engineering Solutions
We all have been in situations where we have seen developers making things more complex than what the requirements warranted. In order to build a robust solution, it is a common temptation for developers to over engineer the solution when a simpler design would have sufficed.
Lack of Focus
Failure to manage the backlog properly can result in distraction for software developers. This leads to switching stories and regular context switching, which impacts the quality of produced software.
If bugs get leaked into production, it leads to fire fighting and developer frustration as they would have to spend time fixing them instead of delivering new software.
Bad Org Structure
As companies get bigger, it is easy to fall into the trap of an inefficient organisation structure, which results in badly formed teams. A team can become too large in size as new people join (with the ideal team size being 4-8 developers).
Another pitfall of having a large team is that they can lack focus, which often leads to unnecessary meetings and internal politics. This results in frustration and reduced productivity for everyone involved.
Any team which gets too large must be split (along with its objectives) into two to keep it focussed and effective.
Bad Communication
Developers are notorious for not being the most effective in communication, especially with non technical people. Not knowing how to communicate can lead to unnecessary friction, conflict and stress for everyone involved.
This can be easily prevented by establishing company wide communication norms, and training people to fill any skill gaps and maintaining consistency across the organisation. Over the long term, efficient communication saves a lot of time.
Lack of Documentation
Very often new developers are left on their own to figure out the historical reasons and context behind why something was done in a certain way. Lack of proper documentation leads to time spent learning what was already known in the organisation.
By documenting all important information like product architecture, business metrics, important decisions and the reasons behind them, it becomes easier for other people to know what they want to know. This saves precious time in the process.
Resource Bottlenecks
Hiring never works in tandem with business demand, which can often result in skewed teams. For example, having two backend developers but only one frontend developer in a team (either due to slow hiring or a resignation) can lead to extra pressure on the front end developer.
This can create a bottleneck and slow down the whole team, and impact the project delivery. Any chain is only as strong as its weakest link, and the same is true for software teams.
Lack of Solid Engineering Practices
Engineering practices like code reviews, automation, unit testing can go a long way in improving developer productivity. If these processes are not established in your organisation, it leads to developers doing the same repeatable stuff which can easily be standardised and automated. Bad tooling and slow infrastructure can also lead to wastage of scarce developer time.
Unfortunately, as I said in the beginning, all of the above points are all too common in our organisations today. In the race to build and ship products fast, we sometimes end up neglecting the above mentioned fundamentals.
This can result in hidden software delays and rework, which can be easily avoided with proactive behaviour. This usually happens due to lack of experience and foresight from the engineering leadership team. As they say, Good judgment comes from Experience, but Experience comes from Bad Judgment.
