Software development: smaller is better
Small is better at all levels of software development: Small projects have lower failure rates than larger projects. Smaller classes are easier to understand and use. Small functions and methods are easier to write, understand, test, and reuse.
I think that the first point is the most interesting. It is difficult to get requirements right and reducing the size of projects by breaking them up reduces risks involved with poor understanding of requirements. To use web applications as an example, by implementing a minimal system that still provides useful functionality, we learn early on what are the most important requirements. We also keep team size small - more efficiency and less risk. We also get something useful to users developed faster.
I think that ego is the negative force that fights against the goodness of small and focused projects. At the customer level, they often want all of their ideas implemented sooner rather than later instead of setting priorities. At the developer level, they may want to push technology choice over satisfying users' needs in a timely and inexpensive way.
While frameworks certainly save development time they also add their own kind of complexity in the form of steep learning curves, selection, and maintenance to upgrade to newer versions.
In many cases I think that a better way to simplify systems is to extend programming metaphors to support application development a higher level. Two very good examples of this are Google's GFS distributed file system and their map reduce libraries. These tools change they way developers think because they do not need to worry so much about scaling their applications. Another good example is Ruby's ActiveRecord: it changes the way I think about persistence and Rails migrations are now my favorite "modeling language" for specifying class definitions even though I am really defining database schema. I argue that the combined notation of using Rails migrations and adding has_many, one_of, etc. calls in ActiveRecord classes captures the useful information in UML class diagrams in a very terse, easy to write, easy to understand, and easy to maintain executable notation. (BTW, the only type of UML diagram that I still use frequently is sequence diagrams.)
I think that the first point is the most interesting. It is difficult to get requirements right and reducing the size of projects by breaking them up reduces risks involved with poor understanding of requirements. To use web applications as an example, by implementing a minimal system that still provides useful functionality, we learn early on what are the most important requirements. We also keep team size small - more efficiency and less risk. We also get something useful to users developed faster.
I think that ego is the negative force that fights against the goodness of small and focused projects. At the customer level, they often want all of their ideas implemented sooner rather than later instead of setting priorities. At the developer level, they may want to push technology choice over satisfying users' needs in a timely and inexpensive way.
While frameworks certainly save development time they also add their own kind of complexity in the form of steep learning curves, selection, and maintenance to upgrade to newer versions.
In many cases I think that a better way to simplify systems is to extend programming metaphors to support application development a higher level. Two very good examples of this are Google's GFS distributed file system and their map reduce libraries. These tools change they way developers think because they do not need to worry so much about scaling their applications. Another good example is Ruby's ActiveRecord: it changes the way I think about persistence and Rails migrations are now my favorite "modeling language" for specifying class definitions even though I am really defining database schema. I argue that the combined notation of using Rails migrations and adding has_many, one_of, etc. calls in ActiveRecord classes captures the useful information in UML class diagrams in a very terse, easy to write, easy to understand, and easy to maintain executable notation. (BTW, the only type of UML diagram that I still use frequently is sequence diagrams.)
Comments
Post a Comment