Author Archives: Greg Jorgensen

The joys of maintenance programming

In the old days when I started programming, green programmers trying to build their skills and get experience started out doing maintenance programming. Only the old hands got to write new code. The newbies cut their teeth debugging and fixing musty old code that still worked for the business. I’ve done my share of new development, but today I do maintenance programming almost exclusively. After working on way too many failed ground-up “green fields” projects I prefer to debug, fix, and enhance production software. I like working with real users rather than making up “use cases.” I prefer building confidence and making my clients happy with my work rather than arguing with them about features, specs, budget, and schedule. I like having a prioritized list of well-defined tasks that refer to existing code rather than trying to blue-sky specifications. I like charging by the hour instead of by the project, and not having clients balk at my rate.
Continue reading

Database Thaw Reheated

In his November 24 article Database Thaw Martin Fowler wrote about the lock-in of relational/SQL databases and some possible alternatives. I was with him until he wrote that “you can’t get [a] bigger breach of encapsulation than that,” referring to a central database shared by multiple applications. (The indented quotes below are verbatim from Fowler’s article).

For many organizations today, the primary pattern for integration is Shared Database Integration – where multiple applications are integrated by all using a common database. When you have these Integration Databases, it’s important that all these applications can easily get at this shared data – hence the all important role of SQL. The role of SQL as mostly-standard query language has been central to the dominance of databases.

That’s a fair argument, though I don’t agree that SQL has been central to the dominance of databases, or central to making shared database integration the “primary pattern” for integration. Before SQL-based databases took over in the mid-1980s, integration through shared non-relational databases was already the norm. SQL standardizes how users and application get data in and out of the database, and how database schemas are described, but it’s just a language that more or less replaced many proprietary and unstandardized languages that did the same thing.
Continue reading

Comment correcting software closes $25m funding

In a little-noticed deal that closed yesterday the Silicon Valley startup apostrophree secured a $25 million first round with Bolus Venture Capital of Palo Alto. apostrophree received seed money from Paul Graham’s Y Combinator earlier this year.

apostrophree is currently conducting a private beta test of their product, a proxy service that corrects common errors of spelling, punctuation, grammar, and usage in blogs and especially comments and discussion forums. I spoke with John Scogan, founder of apostrophree, about his product and company.
Continue reading

Miasma: a new framework for web applications

This is the first interview posted on Typical Programmer. I plan to do more interviews with programmers who are working on interesting projects and pushing new ideas and technologies.

I had a chance to interview Boyd Hakluyt at O’Reilly’s OSCON 2008 in Portland last week. Boyd is working on a new web application framework called Miasma. Boyd gave a demo at OSCON, and afterward we had some of the local microbrew Portland is famous for and talked about web application frameworks.
Continue reading

Doing it wrong: getters and setters

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

Relational Database Experts Jump The MapReduce Shark

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

Comments on Joel’s “How Hard Could It Be? Five Easy Ways to Fail”

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