<shamelessplug>Let me know if you want to learn how to fly!</shamelessplug>I am a pilot, been flying recreationally since 2004 and professionally, as a flight instructor, for just a couple of months now. To me there is nothing more satisfying than touching down on a runway (smoothly, of course), reaching the destination I intended to reach, and doing it safely. Planning a flight that ends successfully begins days in advance of the actual flight. It involves brushing up on systems and procedures for the airplane, checking what type of weather can be expected on the day of the flight, choosing a route to the destination, and also making alternate plans in case the other stuff you planned for doesn’t work out. Most of the effort in successfully completing a flight is done on the ground in the days leading up to the flight, planning for the ideal situation but also for the non-ideal and/or emergencies.
This is not too dissimilar to beginning a new web development project. Lots of planning is needed to ensure that the outcome of the new project is as expected, on time, and within budget. The vast majority of my projects are fairly straightforward HTML and CSS with some Javascript sprinkled in, followed by integration with a Content Management System. There are lots of variables at play throughout the lifespan of any given project that determine how it is completed. Doing an appropriate amount of planning before even opening a text editor can save significant time and frustration down the road.
Look at the big picture first
Where are you now? Where are you going? How are you going to get there? These three questions are important both to the pilot and the developer. Let's look at each of these individually.
Where are you now?
This one is easy. For the pilot, if you're on the ground, it's the airport where your airplane is currently parked. For a developer this may be nothing more than a blank document in your text editor.
Where are you going?
In flying, your final destination is where you're going, which is usually easy to figure out based on the reason you're flying in the first place (i.e. transporting cargo or people to a certain place). For the developer this can be a little more tricky to figure out. Usually it consists of a Photoshop file that was given to you by a designer that tells you how the site is going to look. If there's a site map available, that is included in the "destination" as well. Info about specific functionality also helps round out what a developer needs to know in order to plan properly. If the site map or intended functionality doesn't match the design, which occasionally is the case, it's in your best interest to hash out any questions before you get started. It's pointless to try to come up with a plan if you don't know where you're going. Or course, this is not always practical, and you may need to get started before knowing every minor detail in the interest of meeting the deadline. In this case, make some safe assumptions that will allow you begin, but plan on tweaking those assumptions as the project progresses.
How are you going to get there?
For pilots, the route is where you have decisions to make. You could plan to point the airplane directly at the destination airport with no regard for restricted airspace or dangerous weather that gets in your way. However, this is a great way to find yourself being intercepted by fighter jets or thrown to the ground by a thunderstorm (I mean that literally, by the way). The better decision would be to plan a route that takes you around airspace you’re not allowed in and to stay away from potentially dangerous weather. It's also a good idea to have alternate airports in mind, just in case you can't make it to your destination.
For the developer, route planning also provides plenty of opportunities to make decisions. For example, different environments call for different markup, style, and content structure. When I begin a Hifi project, I approach it differently than I would for a Wordpress project. Regardless of the environment, the final outcome should be fairly consistent, but the route you take to get there (the markup, style, and content structure) could look quite different.
Plan to change your plans
You’ve planned your route, you know what the weather is going to be like, you’ve dotted all of the i’s and crossed all of the t’s. After you takeoff you’re committed, you must complete the flight and make it to your destination using the exact route you planned, right? Not so fast. What if it’s late in the afternoon on a hot summer day, and even though there were no thunderstorms forecast you see an enormous cloud growing 25 miles in front of you? I hope you don't plan on flying straight at it and hoping for the best, because that is a battle you will likely lose. A good pilot is always assessing and reassessing the situation to make sure the planned flight can be continued safely. If you can navigate around the scary storm ahead, do it. If you can’t, turn around and head back to where you came from. If storms are blocking that route too, find the nearest airport or relatively flat open area and land. Never continue into an increasingly dangerous situation without a solid exit strategy that you can execute immediately.
As a developer, I’ve never built a website where I didn’t have to make changes to my plan along the way. There have been times where my initial planning wasn’t adequate and I didn’t account for something I should have. But more often than not, it’s not for a lack of planning but more for unexpected behavior of a feature or changes requested by the client. Regardless of the reason, if something needs to change then it needs to, and as the developer I have to figure out a way to make it happen. It’s possible that a change could mean that the “destination” is going to have to change, or at the very least the route to get to the destination is going to look different than originally expected. In the end, your goal as the developer is to make the client happy and to build a website that accomplishes the clients’ goals.
The point is this: In both flying and in development, make a plan, but plan to change it. Pay attention as you progress and be able to recognize when a course correction is needed. When it is necessary, execute the course correction immediately. Approach every project with a series of backup plans. Know multiple ways to handle common features so you can tailor your approach to the needs of a specific project. And if the approach you thought would work doesn’t, you have another approach ready to go. In the end, development will run more smoothly, frustrations for both you and the client will be kept to a minimum, and the final product will probably be a lot better.
Leave the first comment