Why is programming so hard, especially on seemingly simple problems. Here’s a short piece on the Apple iOS6 Do Not Disturb bug that surprised me. The bug is fixed, as of Jan 7, because it was a date issue. According to the article, the programmers that implemented the Do Not Disturb function used the ISO calendaring dates, which do not work as expected this year. The details are in the article, and it reads like an edge case, but it’s not one I’d expect to have slipped by Apple’s QA department.
These types of programming errors seem to regularly slip by developers. The situation has gotten better since the days of VB6 when it seemed everyone that could complete a week long course was building buggy applications at a frightening rate. While I still think there are plenty of hack developers out there, it seems that with all the publication and information available, there are better programs being built in many organizations.
However simple bugs can still slip through. The maintenance plan bug in SQL Server 2005 showed Microsoft that there’s no such thing as a simple fix or patch. In this case, even the Apple documentation for developers (Fixed Format section) notes that the ISO date should not take precedence when there is a conflict. Apparently not all of Apple’s developers are following their own documentation.
Developing software is easy to do, but hard to get right, especially when you are building software that you expect to last a long time and get used in a variety of ways. Experience, practice, learning from your mistakes, and a deep understanding of the business you are working in help developers write better software over time. It’s a reason why you should ensure you work to retain your talented developers. They are much harder to replace than the lines of code they produce. A new developer may produce the same amount of work in a short period, but I’d wager they produce many more bugs as well.
The Voice of the DBA Podcasts
We publish three versions of the podcast each day for you to enjoy.