Reusability is software engineering's Holy Grail. Unfortunately, over time it has often proven difficult to attain. It's almost impossible to build for reuse on the first try and other times it's just not practical. But it's still an important goal that often does work and leads to many efficiency gains.

In frameworks like Django that utilize an ORM to interact with and store information in a database, reusability faces additional challenges. The object-oriented programming model that is typically the heart of reusable code does not always translate into a relational database. Django's ORM does its best to accommodate this by offering a limited form of inheritance, for example, but it still has many challenges.

Another tendency is to build Django models that store data for overly specific problems. In Chapter 2, we will begin writing models for a product database. It would be very easy to apply model inheritance in an attempt to solve specific problems. For example, we may be tempted to extend a product model into a subclass specific for food: FoodProduct. We then may try and build a subclass specifically for noodles: NoodleProduct. Using inheritance this way often makes sense in other software projects, but when Django maps these models to the database, it can become a mess of entangled relationships and primary keys.

To avoid these issues with inheritance, some Django developers employ various model hacks. This includes things such as pickling attribute data into a text field or otherwise encoding extra attributes into a single field. These are often clever and sometimes very effective solutions, but they can also lead to bad designs and problems later on.

The best advice seems to be to keep things simple. Limit what your app does and the dependencies it needs to serve its core duty. Don't be afraid of developing a large app library.