A long flight to the ESRI user conference got me thinking about how a large commercial jet has similarities to software development on a large project. I know, what you're thinking, this guy has lost it! Just give me a minute to explain.
Looking at a large jet, I often think that it's a miracle that something so large can even get off the ground. To do so, the aircraft must use a lot of energy and fuel, and it needs a lot of space on the ground to get going. Once up to speed, it can easily take off and gain even more speed in the air. The aircraft I'm on is currently doing 528mph (850km/h) seemingly effortlessly.
This got me thinking a lot about building software. I don't claim to be an expert, but I've worked with several software development teams in the past with varying types of management and end-users.
Often times, when starting a new project, managers and end-users want to start seeing results immediately. Can you imagine a jet trying to pull up and take off when it doesn't have enough speed? It would most likely stall and crash, if it could even get off the ground to begin with. This happens a lot of times in the workplace. Managers see the developers working for a few weeks and want to see X number of features working beautifully. A lot of times, the developers haven't even put a front-end on the project yet, and management doesn't have something "real" to look at.
Often times, pushing for seeing these features in completion means that the development team rushes and cuts corners, not thinking about the big picture. I've seen it numerous times. You get so focused on completing these feature tickets, you end up copying/pasting code from somewhere because it's not been written in a reusable way. Or, you rush through writing new code, not thinking about how it could be used in other features of your app. Doing this adds to your technical debt. Managers see these features being completed, and think that you can maintain this speed of knocking out more and more features. Eventually, you will get to a point where the technical debt is so high, making changes to existing features will be extremely difficult, or even impossible.
Having management that is completely on board with the proper take-off procedures is rare. Good managers will be able to push back to the end-users, because they know in the long run, once this project gets off the ground, it's going to really fly!
If given proper amount of time for the developers and architects to really focus on building a good foundation, adding on the the project in the future will be easy. Good software development starts with a good foundation that is flexible and agile. As developers, we should push back to management to give us enough time to lay out the ground work. If the managers can get on board with this just once, they will see how fast the features will start coming together once the good practices and architecture has been laid out.
Take time to abstract away any areas of volatility; logic you know management is likely to change their mind on in the future. Do you find yourself needing the same functionality again and again? Think about how you can move that functionality to a super class, or a service that can be shared amongst your code. For front-end development, this could mean writing generic directives or components, or just a simple class that holds some common business logic.
I promise you, the next time that you receive a ticket to do something similar to features you have already built, you will be able to complete them in no time. Your project is now at 500mph, and your aircraft is agile and maneuverable. It all comes down to that time you spent preparing for the flight, and smoothly accelerating down the runway.
Copyright © 2019 Chris Perko