Every one reading these words has no doubt worried over a problem or two until the answer has become clear. Generally, the best answers are the simpler ones, primarily because we’ve done some thinking, and gotten rid of the unimportant details that cloud the real issue (whatever that may be). The problems in programming are much like that. Get anyone to write code as soon as they hear the problem, and get ready for a mess of code. Give that … Continue reading →

Few programs emerge full-grown and ready to take on the world. It’s a standing joke in the industry to never expect perfection before Version 3.0 – and don’t even think of using version 1.0! Getting software ready involves some compromises, often ending up in rushing products to market too early. Marketing pressures mean that many programs are shipped with possible design and usability issues. The result is that by the time version 3.0 ‘gets it right’, a lot of people … Continue reading →

Despite the way the industry may look at times, software is big business. And businesses need cash flow. For example, let’s say you’ve written the greatest program since the spreadsheet, got it out there, and sold a million copies. Then what? Companies hate that part. You have a product to support, but no further income. The result is that businesses do everything they can to freshen things up, to keep the public buying. Cars look a little different from year … Continue reading →

a taste of older writings… Continue reading →

(originally published in The Borland Developer Network) As part of good programming, assertions in your code are a convenient way to monitor what is happening. This article discusses adding flexibility to assert(), as well as improving your use of it. Some Background on Asserting For many years, I’ve used assert() to manage code: assert(int test) This function takes a test and asserts the test result is true – nothing happens if so, but false results in an alert, allowing your … Continue reading →