Andreas Hausladen came up with a way to get D8 apps to run under Mono. For more information, check out this file from SourceForge.

A couple of people have asked me to write up some more in-depth material on interfaces. I like that idea, and will do it at some point. Until then, here are a few links that I came across that cover the ins and outs of interfaces.

'Interfaces: Off the Beaten Track' by Malcolm Groves
'Code Reuse Through Interfaces' by Rob Collins
Joanna Carter's articles 'Hairier Parrots' and 'The All Seeing Eye'

If you know of other URLs, comment here and I'll roll them up to this post.

I'm sure everyone uses version control on their projects. Version control is useful even in one-person teams. If you're not using version control, then maybe I just found Pet Peeve #3.

When using version control it is imperative that you actually check code in that at least compiles. If it doesn't compile, that means that there is zero chance that you tested it. Not only does it mess up the whole build process, but if you didn't test the code, you'll most likely end up doing another build to fix the build you just got done releasing. I don't care how busy you are, or what kind of excuse you can come up with, there is NO excuse for checking code in that doesn't compile. This also leads to another blog on unit testing and automated testing, but I'll leave that for another day. Now I have to go back and finish fixing the build....

OK, time to start my list of pet peeves. When you write code that results in a hint or warning, don't treat it as a congratulations message that everything is going well. Instead, take the time out NOW to stop and fix the hint or warning. If you start getting sloppy and letting hints and warnings go, then you will inevitably get burned later on as a result of this. One perfect example of this was a project that had hundreds of hints and warnings accumulate over the years. One day, a hard to reproduce access violation got reported. Since we didn't have a test case, we had to walk through the code by hand. Finally, I noticed that a variable could possibly not be assigned in one code path. I then actually said out loud "That's funny. I would have thought a warning would have been generated." In response, the developer said "Could be. I don't know. I turned off hints and warnings because there were so many of them." We turned them back on, and sure enough, there was the warning that I expected. We fixed the code, the warning went away, and so did the AV. Shortly afterwards, we took the time to clean up all of the hints and warnings. Heaven knows how many more potential bugs we avoided by cleaning those up. Hopefully, you can learn from this mistake by just reading this. It's a lot less painful than the alternative.

Hallvard Vassbotn has started blogging. Long overdue, IMO. Delphi programmers would be insane not to keep up with his blog as just about every single thing he posts to the newsgroups is pure gold.

If you were affected by the "persistent field size mismatch exception" introduced in Delphi 7.1, then take a look at the new public beta that Borland released.

I fully believe that having a way to automate your builds is the only way to guarantee good results when building your product. The more complex your project becomes, the more complex your build becomes. This is a bad thing for several reasons, the 2 foremost being that the build becomes time-consuming and error-prone due to manual interaction. Of course, the corollary is that when you get to that stage, there is typically only one (maybe 2) person(s) that understand how to do a full build of your product. Using an automated build tool can help the entire team and the quality of your product immensely.

I have spear-headed the effort to automate builds several times now. Sometimes, it is met with resistance. Sometimes, it is encouraged. But in every case, when the build is automated the end-result blows people away. Comments like "Wow, doing a build is that easy?" are frequently heard. After getting an automated build into your organization, people start seeing many other opportunities to fine-tune the build. "Oooh, wouldn't it be nice if we could schedule this to run at midnight every night?" or "Let's have the build run the test scripts automatically for us" or "Hey, we can add this other utility into the build process to ensure that datasets are closed at design-time!". The results are always well worth the effort. At one company, I took a completely manual build from 4 hours down to double-clicking and 45 minutes. The added benefit of not forgetting steps also made the build more reliable the first time. I imagine results like these are more common than not.

There are several tools out there, and here's my simple list of tools that I find useful. All of them are extensible in the sense that you can create your own actions and have those actions execute whatever you want during the build. In my opinion, that is the absolute best part of creating the build script!

Product	Language	Notes
FinalBuilder	Multiple (Delphi, BCB, VS.NET)	Commercial, but absolutely fantastic
Ant	Java	Open Source
NAnt	.NET	Open Source. Knock-off of Ant

Even if you end up crufting your own automated make together with BAT files and make, it's worth it. So quit standing on the sidelines and get cracking! If you know of other build tools that you find useful, please leave a comment and I'll update the main page.

I was talking with Josh Dahlby back in the day and we started talking about general software development. During that discussion, I think we hit on one of the fundamental tenets of software development, namely "It takes 3 iterations of development to perfect something". This isn't an excuse to ship products with glaring ommissions and bugs, but rather, mirrors the development experience that both of us have had.

The first iteration is your world-beater version. It puts the technology (be it component, framework, or application) out into the hands of the masses. The new "bright shiny object" (thanks to Danny Thorpe!) syndrome takes hold and calls people to your creation like a siren song drawing a ship closer to the craggy rocks. The success of the first revision is short-lived, though. Inevitably, no matter how smart you think you are, and how much time you spent trying to forsee all possible scenarios, users will bring you back to earth to let you know that you failed miserably.

The second iteration implements the feedback you received and makes the product better. The API will change, performance bottlenecks will be solved, and features will be added. People will be happier to use this version as it starts to solve their problems in the way that they want. This is when the product starts to achieve acceptance, and moves from an Early Adopter experience to a Must-Use product.

The third iteration is where you truly understand the problem and start to make things more flexible (better architecture, pluggable components, more user-configurable options, etc.). Inevitably, this version is the one where you can reuse the code easily, and extend the architecture into something aesthetically pleasing - as well as rock-solid. However, now that you fully understand the problem, the typical software shelf life of a product comes in to play, and you start all over with a new product.

Some may argue that they don't go through this cycle. I would argue that either the product you're producing isn't that complex, or more likely, management is allowing you to condense a couple iterations into one (e.g. open betas, longer schedules, etc.). I believe that all products go through this cycle, but whether or not the cycle plays out at clearly defined intervals like version 1.0, 2.0 and 3.0 is not mandatory.

In conclusion, I think it's important to understand limitations to have success. The greatest limitation that you can accept is that you can not possibly understand every way every user would like to use something just by drawing boxes and lines.