"We'll make you a software that will last a lifetime!" - said every brittle code developer, ever.

 Y2K. Ring any bells? Apparently, the world was coming to an end 2 years after i was born. It was a hippie's worst night mare, technology had took over the world and was supposedly going to bring it to its knees in once the timer runs out on the clocks in 1999. So what was Y2K? Instead of allowing four digits for the year, many computer programs only allowed two digits (e.g., 99 instead of 1999). As a result, there was immense panic that computers would be unable to operate when the date descended from "99" to "00". Year 2 thousand, or Y2K, was not going to be documented properly in computers since the dates on computers were recorded in two digits. Many companies including AT&T estimated that more than 50% of their financial and labor resources would have to be spent to fix all the code when the year turns. Why wasn't this addressed earlier? Why were the dates recorded in 2 digits only? Brittle code. 

Brittle code is when older software appears reliable and then fails when altered in a small way or given unusual data. As software grows with a larger base of users, algorithms that do not account for all forms of a specified input data can pose a big problem. As the developers had not anticipated the turn of the century when they were first developing code, they ignored the year 2000 and made it so the year was only recorded in 2 digits. 1998 was recorded as 98. However, this would cause problems in 2000 when 00 could easily be regarded as a calendar reset to 1900 by the computers. 

Brittle code is a byproduct of outsourcing your coding needs to third party developers. Inhouse code productions can eliminate this problem since the needs and requirements of the code are fully understood by the developers. Third-party developers can only go as far as they are instructed. They can not anticipate future requirements or needs for the code. This doesn't mean that every third party code development results in brittle code, it just merely proves the high risk involved with outsourcing development. This is also not to say that inhouse code development can eliminate brittle code completely, Y2K equally effected inhouse code productions as it did to outsourced. 

Instead of "fixing" brittle code, efforts should be made to not allow it in the first place. Thorough research should be done before building and deploying code. Large test cases should be used. In conclusion, brittle code will only be as brittle as you are with your development needs. If you are only looking for a short term solution, brittle code can go a long way because of its inexpensiveness and quick turnaround time, but if you want to build a company around your code, brittle code can quickly cripple your dreams.