June 14th, 2008 — Programming
Every getter and setter in your code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters (also referred to as accessors, accessor methods, and properties) is a sign of a poorly-designed set of classes.
A long time ago programmers discovered that reducing the scope (visibility) of data as much as possible led to more reliable and maintainable code. Before programming languages supported encapsulation or objects, programmers who cared to write better code followed best practices and idioms (what would be called patterns today) that encouraged limiting scope and data hiding. Back in the old days these ideas were discussed in terms of module strength and coupling. To learn the concepts without the distraction of OOP and “design patterns” terminology see Glenford Myers’ books “Reliable Software Through Composite Design” and “Composite/Structured Design”. Continue reading →
January 17th, 2008 — Databases, Programming
In this article relational database experts David DeWitt and Michael Stonebraker compare MapReduce to traditional relational database systems (RDBMSs) and find MapReduce wanting. They make some strong points in favor or relational databases, but the comparison is not appropriate. When I finished reading the article I was thinking that the authors did not understand MapReduce or the idea of data in the cloud, or why programmers might be excited about non-RDBMS ways to manage data. Continue reading →
October 25th, 2007 — Programming
Joel Spolsky’s article in the November issue of Inc. magazine lists five ways to make a software project fail. Joel’s arguments are well-known in the software development community, but probably not to the majority of Inc. readers. Professional programmers will also recognize a few big swipes at agile programming methodologies. Joel doesn’t mention agile by name but if you’re paying attention you know what he’s criticizing. Continue reading →
