While standing in line at the bank, the delicate and complex nature of updating live code struck me. The bank’s computer system reloaded as the teller apologized for the inconvenience. In that moment, which would frustrate most people, I found intrigue. Despite the added wait time, I felt as though my job experience helped quell any potential frustrations.
Whether it’s a software patch or a complete systems upgrade, downtime is a necessary evil of technology. But in businesses that run on a 24-hour cycle, downtime can cause its own set of problems. I found myself dealing with these problems in some of my projects recently. Because of this endless cycle, businesses find it difficult to deploy software updates without affecting user experience.
This week I’ve spent some time in long calls about updating code that’s in production. I have a much greater appreciation for the developers and testers that are constantly working to make sure all necessary pieces are functioning. As I considered the cost of downtime, I realized that properly written requirements were crucial for faster, more efficient development.
In the fast paced world of today’s global economy, it’s necessary to adapt without “breaking things.” While each project or product is a complex set of tasks, goals, and deadlines, a solid foundation is key to success. Well written requirements help define that solid foundation. Furthermore, these solid requirements can facilitate a more productive workflow in both early and later stages of product development.
From a business perspective, the end goal is to meet deadlines, budgets, and grow the business. From an IT perspective, the end goal is to create the best software while not breaking everything else, in the simplest terms. The lack of available downtime opens the door to writing more requirements of higher quality, which helps both businesses and developers meet all of those goals.
While the small inconveniences that come from faltering technology may frustrate us in the moment, I feel that people who work in product development can sympathize with the efforts to reduce user experience pain as much as possible.
Have you noticed that your response to frustrations with technology has changed with you exposure to requirements and software development? Share a story about a time when your expertise helped you better understand an everyday situation in the comments below.
