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 →
The joys of maintenance programming
February 26th, 2011 — Business and Clients, Programming
Tips for successful freelancing
January 15th, 2009 — Programming
I’ve been freelancing for over ten years, sometimes moonlighting when I have a full-time job, sometimes doing just freelance work. I’ve learned a few things about successful freelance progrramming. Continue reading →
Database Thaw Reheated
December 4th, 2008 — Databases, Programming
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 →