Note to site visitors: this website is a time machine, left pretty much in the exact state it was in at the end of 2006, when site editor and publisher Daniel Read retired from working on it. Please enjoy the 100% free, ad-free content, most of which is still relevant, as developer.* was always dedicated to the "timeless" aspects of technology and software work. Regretfully, as of this writing, the "Community" side of the site, which featured blogs and article comments, has not be restored after a database corruption occurred in the Drupal MySQL database. (If any Drupal experts out there would not mind helping me get it back online, I would accept the help.) Most if not all of the blog/comment content should still be available in the Archive.org Wayback Machine. Thank you to everyone who supported or contributed to this site in it's 2000's heyday. This one of the first sites of its kind. (We even had a theme song!) Please check out the "About" page for more information about how the site was put together from a technical standpoint. --All the best, Dan. (If anyone would like to get in touch, please find me on LinkedIn.)

Finding commonality among classes makes for effective object-oriented programming. Often, programmers express that commonality using an inheritance hierarchy, since that is one of the first concepts taught in object-oriented programming. We're going to go to the other extreme in this chapter to explore the difference between using inheritance and using interfaces. An excerpt from Interface Oriented Design.

The key to maintaining a good employment outlook in IT, it seems, is to move out of programming and up into more business-oriented IT positions such as systems analyst, business analyst, project manager, or systems architect. However, a computer programmer can't just decide to become a systems analyst or project manager overnight.

At a breakfast seminar here June 6 on "Factors for IT Project Success and Failure," Prof. June Verner of NICTA provided a fascinating mix of surprises and predictables related to her subject topic. The findings came from NICTA’s study of 400 projects in the U.S., Australia, and Chile, using questionnaires and interviews to discuss success and failure factors with practitioners.

When we’re testing any software, we are faced with the tradeoff of cost and benefit of testing. With complex software, the costs of testing can grow faster than the benefits of testing. If we apply techniques like the ones in this article, we can dramatically reduce the cost of testing our software. This is what we mean when we say test smarter, not harder.

Once we realize that we are committed to a future full of testing, it is worth exploring what testing really means. I would assert that there are several flavors of testing, and that all too often when we speak of testing we consider far too few of those flavors. An excerpt from Software Conflict 2.0.

A new installment in the developer.* Systems and Software series, exploring the connections between general systems thinking, cybernetics, and software development. Author Don Gray applies systems thinking principles--including "balancing loops," symptomatic and systemic solutions, and "shifting the burden"--to a recurring situation with one of his clients.

So what does it mean to be a professional programmer? What does it mean to be a professional anything? Some definitions simply say to be a professional is "to make money from a skill," but true professionals also have a set of qualities often described as "professionalism." In my opinion, these qualities are...

In this article I will begin with a discussion of home-grown vs. off-the-shelf persistence solutions, including areas to consider when deciding between the two, and advice for choosing the best off-the-shelf solution to meet your needs. I will also share suggestions and advice from my own experiences with O/R mapping and persistence APIs, with a focus on "best practices."

These essays by Jack W. Reeves offer three perspectives on a single theme, namely that programming is fundamentally a design activity and that the only final and true representation of "the design" is the source code itself.

I’m well acquainted with such people because I display all their qualities. What we share is an honest dedication to our work--so much dedication that we abuse our own bodies, if necessary, to get the work done.

How important are software design skills to a programmer? The traditional view is that programmers merely implement the designs of other people.