90% of Software Developers Don’t Truly Care About Productivity
This post will provide irrefutable evidence with practical examples to demonstrate that most developers tend to take the selfishly long scenic route, not the shortest and most efficient path to delivering results when building web applications.
It is highly likely that anyone in the business or coding side of the software development industry would find this relatable.
In my 25 years of writing code, building enterprise applications, and managing teams of dozens of software engineers, I’ve come to the conclusion that the vast majority of developers simply don’t have the capacity or motivation to prioritize organizationally-aligned productivity.
They’re more concerned with building cool features, making their code super-flexible and clean, building up the tech stack listed on their resume, and working on interesting projects. We’re like herd animals; everyone else is building microservices with a React front end, so we should too.
So, why should they care about productivity? Here are four reasons:
- Increased productivity leads to increased profits.
- Faster Time-to-Market, get faster product feedback from customers
- Better alignment with business objectives
- A truly productive team is a happy team with happy stakeholders — and happy employees are more likely to stay with your company.
What “productivity” ACTUALLY means for most developers
The typical developer will think about productivity meaning the efficiency and effectiveness with which they can write code and create user-friendly software applications and websites. This involves leveraging a wide range of technologies, techniques, and best practices to develop high-quality products within a given timeline.
Productivity is as much about following quality standards as it is about meeting deadlines since poor software development that does not meet users’ needs has little benefit for any organizations or individuals.
Developers should have working knowledge of the systems, processes and coding languages that are most useful for creating modern, efficient developments that deliver the highest value. Productivity also means finding the best ways to solve problems that arise during the development process.
Sounds reasonable right, but it's missing a key component…
What productivity SHOULD mean for developers
It’s all about the decision criteria used when deciding on architecture and how to deliver user features. Cost and Time to Market don’t often enter the equation, especially in larger organizations.
There are a few simple questions that developers should be asking but rarely do:
- Am I about to embark on a journey of solving a problem that’s already been solved by other development teams half a million times?
- Is there a tried and true open-source platform or library that already does a significant portion of what I need to accomplish?
- Is there a third-party paid solution available that already does a significant portion of what I need to accomplish?
#1 almost never get’s asked: it just isn’t something that often happens. Developers want to build from scratch without a second thought to another more business-centric option.
#2 is ENORMOUS: Ok, so developers are pretty good about using libraries for minor challenges like dealing with dates or filtering and manipulating arrays. Anything that’s painful and lacks fun might get a library imported into the project.
But what about developing RESTful services? Does it really make sense to start from scratch as opposed to using a platform or framework that already has dozens of tried and true features that you’ll have to build yourself as you go? Think ORM, logging, tracing, security, modularization, utilities, unit and integration testing, plugins for specific needs, and so on.
Low code platforms are another prime example — in some cases, these tools can literally and I mean LITERALLY cut the overall development of your project by well over half, yet the average developer would be hard-pressed to even tell you the name of one for the tech stack that they specialize in. SonicJs for example can allow you to build the entire administrative section of your web app with zero code and
#3 is HUGE: Developers will typically gloss over any solution that is paid for. This just doesn’t make sense from a business perspective. The problem is that most developers are not business minded, they are problem solvers and use an entirely different mix of decision criteria when applying their critical thinking as compared to say a product manager or startup founder.
Let’s look at an example
Most apps need some sort of user authentication allowing users to create accounts, log in, etc. Passwords need to be stored in an encrypted format, users can be assigned roles, and each role can be mapped to various permissions, some covering only specific areas of the application and others spanning the entire system. Administrative screens are required to manage all of this. Additionally, the system should be performant and intuitive.
Here is a quick example and the math is simple:
Option A — Build a Homegrown Solution
Developer spends 500 hours @ $100/hour to build user authentication (via email, LinkedIn, Google+, etc) into your enterprise app
Cost: $50k
Time to Market: 3 month
Option B — Buy and configure and off the shelf package
Developer spends 60 hours @ $100/hour configuring, integrating, and extending a third-party solution that does 90% of what you want. The solution comes with a $4k annual licensing fee
Cost: $10k
Time to Market: < 1 month
Sadly, Option A wins 90% of the time
I’m not exaggerating here, Option A almost always wins. Option B isn’t often even considered and is never given to business stakeholders as an option. Read on for some insights into why this happens again and again.
95%+ of Developers have never had to manage a budget or work on a fixed-bid project.
It is quite striking that the vast majority of professional software developers have never had to manage or work with a budget, much less complete a fixed-bid project — even though the estimated cost of a software project can often be one of the most influential factors in deciding whether or not the project is even worth pursuing in the first place.
Even so, managing budgets and fixed-bid projects are important components of development and it is essential for experienced developers to learn not only how to code effectively, but also how to understand and optimize resources available at their disposal — skills that every successful software engineer must attain.
In my experience, maybe 5 out of 100 engineers think this way. Software managers aren’t much better — many are often promoted due to having strong tech skills and good communication skills, not necessarily as a result of having the business acumen you would tend to find with managers in other areas of the business, especially compared to sales and marketing roles.
Simply put, the time-to-market aspect of software development is often much lower on the list if not completely void against competing decision criteria such as flexibility, working with the latest technology, code quality, tooling, CI/CD, etc.
Developers care more about their day-to-day coding experience than delivering solutions to customers in a timely manner by a landslide. A developer will gladly spend a week automating a five-minute cumbersome task that they might have to perform monthly without a moment of consideration that this will in reality generate a negative ROI. Worse yet, their dev manager is often the one advocating for this type of non-business-added mini-project.
90%+ of Developers have never worked at an early-stage startup
With the growth of technologies such as cloud computing, time to market is becoming increasingly short for releasing products. For early-stage startups looking to capitalize on the competitive edge of being first, having a committed and experienced development team is critical for success.
However, with over 90% of software developers worldwide never having worked at an early-stage startup, getting to MVP fast is still a challenge many organizations face. The demand for experienced developers in this space has motivated companies looking to provide such talent with valuable expertise and rapid time-to-market solutions.
When you are working for a startup, there just isn’t time to mess around with building everything from scratch and analyzing the crap out of everything. You either deliver to your customer in a timely manner or the startup runs out of money and the startup has a hard/impossible time raising more money because they haven’t proven that they are capable of moving fast enough.
We’re Introverted Sensitive Babies
So, We hold productivity hostage…
Over the last decade or so, business leaders have learned that if they push developers too hard, they leave for greener pastures, often without ever communicating their dissatisfaction to management ahead of time. We’re a sensitive bunch and most of us aren’t comfortable pushing back or setting boundaries. Worst than that, most of us don’t have the capacity to understand why management is dissatisfied with our pace of development in the first place. This is proven by the fact that the average tenure for a software engineer is only 2–3 years at any company.
Measuring productivity
Measuring productivity can be a complex process, as it involves understanding how much time and resources are consumed to create and deliver outputs. Many factors influence the rate of production, so different methods must be implemented to get an accurate picture. One method for assessing productiveness is called labour utilization and measures working hours against output generated. This can help identify where more staff may be necessary or how inefficient processes are being conducted.
Another way to measure productivity involves examining real-time data, such as materials required and finished goods produced, in order to recognize areas of wastage or subpar performance. Finally, cost-per-unit calculation helps companies understand how much they are spending compared to demand in order to decide if they should adjust their prices or reorder supplies. Through careful evaluation of productivity metrics with these methods, businesses can maximize efficiency, profitability, and otherwise thrive in their industry.
With all that said, measuring productivity for software products is very hard. You are always building something new, so there isn’t a baseline of comparison. Scrum development processes can be helpful for setting pace and forecasting, but again how do you know how your pace compares to another team building a similarly scoped enterprise-grade application?
Introduce the 80/20 rule and how it applies to developer productivity
The 80/20 rule, also known as the Pareto Principle, is an often-cited concept that has applications in many contexts. In terms of developer productivity, it suggests that approximately 20% of a developer’s efforts account for roughly 80% of the overall result. This ratio can be applied to any complex process or task and is particularly useful when distilling the most effective areas to focus on.
In software development, this might mean concentrating efforts and resources on that 20% of tasks that yield the greatest impact for time and expense invested. Knowing where applicable, understanding what processes will enable greater value from that small portion and having systems in place to optimize processes are all important parts of maximizing productivity from consulting with developers and companies alike.
So how do we increase productivity for both individuals and teams
Productivity for both individuals and teams can be improved through various methods including the adoption of low-code platforms. These platforms allow developers to create in-depth applications quickly, requiring minimal effort, time, and cost.
For businesses seeking to increase their productivity, low-code software is a great place to start. There are some free low-code solutions, such as the SonicJs platform (full disclosure — I am the author of this project), however, if low-code platforms aren’t an option due to budget constraints, consider looking into open-source platforms and libraries. Open source software offers some of the same benefits of low code platforms at no cost; however, this tool often requires more programming knowledge than low code software.
With the right combination of low code and open-source technology, businesses can successfully increase their productivity with minimal effort.
Architecture also plays a huge role in productivity
The software development industy has largely, and blindly in my opinion ditched monolith architectures in favor of microservices. After having worked on a few massive monolith to microservice re-writes over the last several years, one very sad fact has sunk in: Microservice development takes roughly twice as long to develop compared to their monolith counterparts. We solved 10 challenges by migrating to microservice but created 20 more along the way. Not good!
This is just an example but an extreme one and unfortunately a very common one. At some point a collective “Oh no what have we done here” moment will come, but until then I expect dev leads everywhere to continue advocating for this model, since again they really don’t care about the time and cost as long as they get to add the new big buzzword and all the associated tooling and services (Amazon AWS, Google Cloud Platform, Azure, etc) to their resumes.
Key takeaways
The article highlights the valuable insights one can gain by taking a different approach to business strategizing. By considering the problems and objectives of an organization holistically and envisioning what success would look like, organizations can gain clarity on their purpose and determine steps in order to achieve their goals.
Additionally, while it is useful to consider outside advice, entrepreneurs should follow their own creative paths and trust in their capacity to generate innovative solutions. This mindful strategizing process will help organizations to unlock greater potential within the environment they operate and ultimately improve their competitive position.
In conclusion, it is important to remember that productivity for developers means different things at different times. There is no single silver bullet solution that will work for everyone all the time. However, by understanding the various ways to measure productivity, and utilizing tools like the 80/20 rule, leveraging low code and open-source platforms, developers can increase their chances of being productive both individually and as part of a team.
What are some things you have done to increase your productivity as a developer? Have you ever advocated for using a low code or third party solution versus building from scratch?
Share your insights in the comments below.
