urn:lj:livejournal.com:atom1:zunger Yonatan Zunger Yonatan Zunger 2010-03-19T03:45:33Z urn:lj:livejournal.com:atom1:zunger:167779 2010-03-19T03:45:33Z 2010-03-19T03:45:33Z While reviewing some code today, a principle of software design somehow distilled itself to clarity in my head. <br /><blockquote>When designing your system, think of every major system¹ upon which your own system directly depends² as a bug.</blockquote><br />By "think of it as a bug," I mean that sooner or later, you are going to come to truly hate this dependency. It won't do what you want, or it will turn old and crufty, or it will get outdated, or your system will outgrow it. Perhaps it already stinks. And therefore, think about what you are going to have to do to take it out and replace it with something better, and possibly not even having similar API's.<br />Yes, you should have your code sufficiently factored and modular that such a replacement will be minimally invasive. But more importantly: if that replacement requires any change in the API's³ by which the outside world is using your system, then there is something wrong with your design. Stop and fix that immediately.<br /><br />¹Both external dependencies and major subsystems of your own code. Both will suck in time, I promise you.<br />²If the systems upon which you directly depend have done this properly, you don't need to worry about your indirect dependencies. If they haven't, then you should consider replacing them <i>now</i>, because you are obviously dealing with the work of madmen.<br />³Or UI's, if your software is at the top of its software stack. UI's are just API's for communicating efficiently with humans. (Or perhaps API's are just UI's for communicating with computers?)