| |||||||||||||
On breaking thingsOn breaking thingsPosted Dec 1, 2010 19:59 UTC (Wed) by mpr22 (subscriber, #60784)In reply to: On breaking things by RogerOdle Parent article: On breaking things
It doesn't take long, observing humans, to realize that they will routinely and repeatedly put off doing anything about something that is not yet a clear, present, and immediate problem for them, especially if they can come up with a good reason why someone else should do it instead, and even people who are aware of this phenomenon are guilty of it. Tell them "your program will break when version x.(y+1) comes out and removes x.y's transitional compatibility with x.(y-1)" and they'll say "ok, I'll fix it when x.(y+1) comes out", then go into a blind panic when x.(y+1) really does come out and really does break their program.
(Log in to post comments)
On breaking things Posted Dec 1, 2010 20:20 UTC (Wed) by RogerOdle (subscriber, #60791) [Link]
That is very true but some people are forward looking though. It doesn't help that their source of income can be changed because a core component works differently after an upgrade. Upgrades are important for security and stability. They can not be ignored. Planning for a change like memcpy is better than hitting people cold.
On breaking things Posted Dec 2, 2010 9:04 UTC (Thu) by mpr22 (subscriber, #60784) [Link] People responsible enough to be forward-looking about these things should be expected to have read the documentation for the APIs they use, and to accept that if they used an API contrary to the established international standard, it's 100% their fault and their responsibility when their program breaks.
|
|||||||||||||