Convenience-Driven Development Is Killing Your Engineering Culture
We live in an era of "Fast tech", a culture defined by trend-chasing and more importantly, convenience-first thinking.
This has come from outside of the tech world, think fast food and fast fashion.
We no longer buy high-quality clothing that lasts for years, we buy what’s trendy this season and get rid of it the next season.
We don't cook food anymore, we order in(which can be a lot more expensive).
We know that this fast food is terrible for our health, but we take convenience over good. We also know how bad fast fashion is for the planet, but we still buy it.
Unfortunately, we have allowed this to enter into tech. We have created Fast Tech. We want all the features and we want them now, without giving any thought about the impact it will have on the systems we build.
Root cause
The root of fast tech isn’t bad developers, it’s weak leadership.
After 12+ years in this industry, I’ve seen the same two patterns over and over:
- Technical leadership can't say no
- Technical leaders focus on delivery, not engineering
Only one company that I have worked at has avoided these issues. Why? Because their tech leadership knew how to say no, and they said it constantly. They were also highly focussed on the engineering which allowed for better delivery.
Leaders like this know how to resist the pressure of the crowd and how to think critically about what lines up with the company and software goals long term.
These are rare traits that need to be safeguarded. If you have team members in your team that display these traits, you need to encourage them, they will save you more time and money than you can imagine.
How do we fix it?
Get better leadership. But, that's the hardest thing to change, especially in the short term.
But here are a few things you can start doing right now:
Understand the problem you are trying to solve
Stop trying to build out a solution before you have given it proper thought. First figure out what problem you are trying to solve.
Break the problem down
Divide and conquer. When you divide the problem up, you force yourself into first principle thinking.
Once you have the problems broken down sufficiently, finding solutions to those much smaller problems are often quite simple.
Choose your tools carefully
Once you understand the problem and you have broken it down, you can now start asking what's required to implement the solution/s.
- Do you need a framework?
- Could you write a small utility that could give you the functionality you need?
- Is there a library that you can copy only the code you need instead of needing that extra dependency.
If the companies I worked for followed the above rules, it could have saved hundreds if not thousands of dev hours.
Which means more time for new features, maintenance, tech debt etc, which can lead to a compounding effect of more time saved over the long term.
Final thoughts
These issues are relatively simple, but it requires one thing, leadership that is willing to not appeal to the masses.
In tech, appealing to the masses drives almost all of the poor decision making. It's the reason that they cannot say no. They feel pressured to follow the masses instead of doing what's right for the long term.
If you want to push for this kind of change, you will need more than logic, you will have to sell the vision.
Another great article on the topic of Hype Driven Development, which is similar to the current topic, can be found here https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22