Hitting the Brakes to Speed Up!
Growing up, my Father always said the phrase, "They would have to hit the brake to speed up!" Most of the time, this was said at a green light as a distracted driver sat idle. Growing up I just always considered it one of those silly things to think about. The idea that stopping would increase a person's speed was created for comical relief. Yet, I think this applies to the development cycle, and I can't help but feel that there might be some truth packed in here.
There are many different methodologies for development and everyone is always interested in building the most efficient method for their organization. Most of the time efficiency can look like "speed". A lot of time when looking at developers you are wanting to always make the process more streamlined because you are wanting to deliver the new code for the customers/partners/whomever. There is a point where you cross a line from streamlined into rushed coding.
I think that most of us have heard the phrase, "Do you want it done right, or do you want it right now?" In a perfect world we would all say, "We want it done right", but I think that choice is made less and less. I do think of course, there is a time and place for rapid development. When you are patching critical issues, of course they need to get out the door faster. However, this cannot be the expected pace for developers all of the time. There needs to be a pace that is in the middle, not slow, but not dangerously fast.
I find that rapid development is very appealing at first. There seems to be high rewards for the actions taken and the outcome received. Developers were able to crank out all of these new pages/features and functions and it works? Great! Yet there are a few micro-cracks that this creates in the code base as a whole.
Maybe the developer did not document well. Which is fine until another developer comes in and needs more information. Or does not have all of the information and breaks some code 😬
Maybe the developer got the code to compile and work, but not as efficient as it could of. Nothing killer on the app, but a few half-second load times add up over time 🙂
A developer may have not finished everything they needed to, but now they are being pressed to move to another "high priority item" that is treated with the same rush as the last item.
There are other possibilities of course that could cause more micro-cracks in the code. A lot of the time I think these problems are silent killers to an app. They cause slowness after a year or two of development like this. Maybe development has to slow down because the documentation is poor, and new developers spend their days trying to understand or completely rebuilding code sets. So what was once considered speedy and agile development is now causing app sluggishness or untimely code development.
The Way Forward
I cannot give you the formula for your organization. Each company functions differently depending on the people that you have, and the culture that is at your organization. Let me list some guiding principles I apply to most situations as I try to update and overhaul them and I believe they apply here as well.
Don't Over Structure
It is very easy to want to build a system or a brand new process to fix all of the problems. I would advocate adding as little structure as necessary to accomplish the task. The more walls you put up the less mobility the development team has to manage/scale the app well. Keep it simple. Spend the time reviewing the process and removing as much as possible. While keeping the necessary items, code reviews, light documentation, etc.
Just a "Quarter Turn"
It's in my nature to find a problem and crank the heat up to 100% and get the problem solved. I would rather take a play from Bob Goff in his latest book, "Dream Big", he talks about this idea of a "quarter-turn". Let us bring up the heat in specific areas a quarter turn at a time.
When you are managing a team, making "all of the change" at once is not going to benefit the organization. Muscles are torn with a 20lbs addition added. Then again and again. Until you find yourself lifting 100lbs more than you used to. It was those slow quarter turn gains that lead to the 100lbs total increase. You cannot expect a team to go from 0 to 100; there needs to be a quarter-turn of heat added.
I also find that you expose your stress points on the development process, and you are not under as much pressure, which allows you to patch up the process and ensure it gets fixed correctly.
Implement with Consistency
Regardless of anything I do or try to do, I find that being consistent is the hardest step to take. Sure I can build a 365 fitness plan. Yet, the implementation of this plan is only as good as the daily steps I take to accomplish it.
Give you and your team grace, when you fail at it, but get back on the horse and ride! Ride towards a more consistent process!
Final Thoughts
App development is crucial. Building a good process and understanding the development cycle could make or break a SaaS business or any organization dependent on developers for that matter! There are a lot of ideas about development out there. Take the time you need to implement the right one! And always be aware of the dangers of pushing on development for rapid code.
Know that building good coding habits and following through on your process will inevitably allow your app to scale. Spending less time on re-work or re-builds or frustrated developers, and more time coding nice and slowly. I think of it like exercising, when lifting weights form matters most, without proper form you will not be able to lift the max amount of weight, and you risk injury. So take the time you need to get your whole team to have good proper "form". 💪
So maybe we all could take a playbook from my dad, and hit the brake a little bit to ultimately gain the speed we need to move our companies forward!