Comments on: Code Size is the Enemy? http://www.eriknovales.com/blog/index.php/2007/12/25/code-size-is-the-enemy/ Game and Software Development, plus other stuff Wed, 06 Oct 2010 14:13:06 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Erik Novales http://www.eriknovales.com/blog/index.php/2007/12/25/code-size-is-the-enemy/comment-page-1/#comment-41 Erik Novales Sat, 29 Dec 2007 05:05:06 +0000 http://www.eriknovales.com/blog/index.php/2007/12/25/code-size-is-the-enemy/#comment-41 I think one common failing in a lot of APIs is the failure of the designer to actually think about how it is going to be used -- shocking, I know, but unfortunately way too common. One symptom of this is the "kitchen sink" API (in which the user is left to figure out which pieces go where in which order, at their peril). This is why I guess I associate massive APIs with poor design. I think a couple of examples of <B>great</B> API design are the APIs for the Miles Sound System and Bink movie player. Miles provides a "quick" API, which is extremely simple and powerful enough for many games, as well as a more complicated API for games with demanding sound requirements. The quick API is a good tradeoff between ease-of-use and power, but it doesn't limit the power of the library as a whole. And as far as Bink goes, you can get basic functionality working in something like 10 lines of code, and doing more specialized stuff with movie playback isn't much more difficult. For a library that is doing a lot of stuff under the hood, it's amazingly easy to use. I think one common failing in a lot of APIs is the failure of the designer to actually think about how it is going to be used — shocking, I know, but unfortunately way too common. One symptom of this is the “kitchen sink” API (in which the user is left to figure out which pieces go where in which order, at their peril). This is why I guess I associate massive APIs with poor design.

I think a couple of examples of great API design are the APIs for the Miles Sound System and Bink movie player. Miles provides a “quick” API, which is extremely simple and powerful enough for many games, as well as a more complicated API for games with demanding sound requirements. The quick API is a good tradeoff between ease-of-use and power, but it doesn’t limit the power of the library as a whole.

And as far as Bink goes, you can get basic functionality working in something like 10 lines of code, and doing more specialized stuff with movie playback isn’t much more difficult. For a library that is doing a lot of stuff under the hood, it’s amazingly easy to use.

]]> By: Jeremy http://www.eriknovales.com/blog/index.php/2007/12/25/code-size-is-the-enemy/comment-page-1/#comment-40 Jeremy Thu, 27 Dec 2007 03:37:10 +0000 http://www.eriknovales.com/blog/index.php/2007/12/25/code-size-is-the-enemy/#comment-40 Yeah, I completely agree with you sentiment that things should be as simple as possible and no simpler, and that some things are just complex by nature. Good design is a real trick - more an art than a science. Dividing up functionality into modules and arranging APIs to fulfill needs and make sense requires not only clearheaded thinking but sometimes the ability to see into the future. Suggested practices for good design try to solve problems of human nature: people would rather code than plan ahead and people don't like changing things they've already written. Traditional OO design requires the planning up front with less rework later while agile programming lets you do without the planning if you are willing to bravely rewrite huge swaths of code later. Size isn't always the dividing line between maintainable and non-maintainable. I've used large off-the-shelf products that are easy to reuse with clear APIs and ones that were hideous nightmares. A little design talent goes a long way I think. Yeah, I completely agree with you sentiment that things should be as simple as possible and no simpler, and that some things are just complex by nature.

Good design is a real trick – more an art than a science. Dividing up functionality into modules and arranging APIs to fulfill needs and make sense requires not only clearheaded thinking but sometimes the ability to see into the future.

Suggested practices for good design try to solve problems of human nature: people would rather code than plan ahead and people don’t like changing things they’ve already written. Traditional OO design requires the planning up front with less rework later while agile programming lets you do without the planning if you are willing to bravely rewrite huge swaths of code later.

Size isn’t always the dividing line between maintainable and non-maintainable. I’ve used large off-the-shelf products that are easy to reuse with clear APIs and ones that were hideous nightmares. A little design talent goes a long way I think.

]]>