Archive for the 'Development' Category

We are lucky to get positive feedback about SmartInspect regularly, but once in a while there is an email or blog comment that really stands out. Kevin Powick of Trident Information Systems sent us such an email and we are happy that Kevin allowed us to publish it:

“I’m writing to tell you how pleased I am with SmartInspect. I had a nasty bug in one of my Windows Service programs. The service was silently aborting, even though the exact same codebase ran fine as a stand-alone application. I tried doing some logging of my own to text files, but I still could not find the problem.”

“After about a week of this nonsense I purchased SmartInspect. I spent maybe 40 minutes adding SmartInspect logging throughout my code, and 5 minutes after SmartInspect produced its first log file, I had the problem solved!”

“I don’t think I ever would have figured this out without SmartInspect. Thanks for a great product.”

Thanks a lot Kevin! It’s really great to hear how SmartInspect is helping customers to solve real-world problems. Did you have a similar experience with SmartInspect? We would love to hear from you.

I have never used Visual Basic in my life and can only guess how much pain it must be for those who have to maintain VB6 applications after Microsoft abandoned the product. Fortunately for those developers, there are tools that can help with the migration to other platforms. I recently came along VB Migration Partner, a new tool that automatically translates VB6 applications to VB.NET. Judging by the feedback of beta testers I read, it does a very good job of translating the various VB6 quirks to VB.NET. Have you used such a tool in the past? Are there better alternatives like migrating to Delphi?

(Note: Although this is primary a C#/.NET thing, this is also posted on DelphiFeeds.com as I think this might be interesting for Delphi developers as well. Maybe this or a similar abstraction is even something to consider for the DPL?)

I did the final presentation for my CS Bachelor thesis at the University of Paderborn today. I thought I would share the thesis here, maybe some of you find it an interesting read. In one sentence, it’s about simplifying concurrent programming with several (new) higher-level abstractions. Here’s the summary:

Although being touted as the next big thing for years now, concurrent programming is still very difficult and error-prone even in modern programming languages and environments. Concurrent and in particular multithreaded programming still requires deep knowledge of low-level techniques like threading or locks and experience with deadlocks, race conditions and other subtle and hard to find concurrency problems. High-level concurrency abstractions and patterns can simplify concurrent programming but are only starting to become available in modern mainstream programming languages.

One of these high-level abstractions is the so called Active Object pattern. The Active Object pattern works, as the name implies, on the object level and not on an object hierarchy like most other design patterns. With an active object, method invocation is decoupled from the actual method execution, i.e. invoked methods of these objects are executed asynchronously and do not block the caller. There are several variants of this pattern known, but all have in common that the concurrency functionality is achieved by running methods in a thread or process context different from that of the caller. Possible results of active methods are encapsulated in so called future objects which can be seen as placeholders or contracts for the real results.

I will post the related code (the active objects runtime library as well as the related code generator/compiler) later this week or maybe early next week. So without further ado, Active Objects and Futures: A Concurrency Abstraction Implemented for C# and .NET.

Holger Flick just announced a beta version of a logging class for SmartInspect to log ECO objects. For those of you who have never heard about ECO, it’s “an application framework that allows you to take applications from design to implementation in a much shorter time.” It’s a .NET framework that originally shipped with Delphi C#Builder and is currently being prepared for a broader release by CapableObjects, a newly founded company that took over the development of ECO. Holger does a very good job explaining what ECO is and how it can be used to speed up the development of database applications. His new logging class definitely looks very interesting for ECO logging as such highly abstract frameworks tend to be harder to debug than normal projects.

Marco Cantù just released his Delphi 2007 Handbook which can now be ordered directly from Lulu.com. To quote Marco on his new book:

“After writing 8 Mastering Delphi books, I’ve come to the decision that the Delphi community needs something different. Rather than writing an all-encompassing book, covering both introductory and advanced material, I think it makes more sense to write a book focused on existing experienced Delphi developers.”

“As many of these developers have missed the last couple of versions of Delphi, the aim of the book is to bring them up to speed covering the most important features added since Delphi 7. In most cases the material goes into some depth as it is not meant for beginners. Some of the new technologies, though, are only briefly covered as a way of introduction.”

I think this is a very smart move as the number of new Delphi developers has declined over the recent years and if you want to sell a new Delphi book, you better had some interesting content for existing users. By the way, Marco also posted some interesting blog postings about his experience with self-publishing a book on Lulu.com. Interesting read!

A condition variable is a threading abstraction which can help in implementing robust multi-threaded code. Condition variables are core features of Java (Object.wait, .notify, .notifyAll) and .NET (Monitor.Wait, .Pulse and .PulseAll) but we needed an implementation for Delphi. I couldn’t find one so we wrote my own. If you are interested in (using) the code, we made it publicly available on the following page:

Win32 Condition Variables and Monitors for Delphi

Comments are welcome.

Does your software application have bugs? Of course it has, every software application that’s out there has bugs and bug-free software is a myth. But it’s still possible to greatly minimize bugs, security problems and errors in your application by following a few tips and techniques I outline in this posting.

Recent studies show that up to 40% of system failures are caused by software bugs and that common memory and concurrency related bugs account for 60% of system vulnerabilities and security problems. So reducing software bugs in your application is the best way to increase the stability, reliability and security of your software.

During the development of our logging tool SmartInspect, we used many techniques to keep the quality of our product high and this list contains some of the techniques we use. So without further ado, here is my list of 12 practical tips for building bug-free software (or at least software with fewer bugs):

1. Code Reviews

Four eyes see more than two. That’s why you should let other developers review your source code on a regular basis. Pair programming on the other hand, a technique where two developers write code together for longer periods, isn’t for everyone and is often not needed. But complicated, important or security related code greatly benefits from code reviews and will improve your code quality a lot.

2. Beta Tests

Beta tests play an important role with keeping your software’s quality high. But most times, it doesn’t make sense to release beta versions of your software for minor updates. Major releases on the other hand, should be tested by end-users and customers before going gold. You can test your software as much as you want, if you cannot control the execution environment, the chance is high that end-users will find bugs and problems with all the different computer configurations out there. Also make sure that your software reached a high quality standard before giving it to beta testers. You don’t want to waste the testers’ time by letting them find and report bugs that you already know about.

3. Automated Tests

Automated tests like unit tests or automated GUI tests can be used to guarantee the functionality of application modules, application programming interfaces (APIs) and user interfaces. You don’t have to be a test-driven development wizard to make good use of automated tests. Using unit tests for key parts of your application can go a long way towards building more reliable software. There are tons of unit testing frameworks, web and GUI testing tools out there that you can utilize.

4. Logging

Using log files or live logging during development and production usage is an important and useful technique to identify bugs, find concurrency problems and to analyze and find out why an application crashed. Advanced logging tools are also able to log complete objects, trace threads and distributed systems and offer rich viewer tools to monitor your application. Instead of writing your own basic logging framework, you should use proven and advanced libraries and tools. Many open-source and even some commercial offerings have been released over the years, including our own .NET, Java and Delphi logging tool SmartInspect.

5. Error Reporting

To find and resolve errors and exceptions, you first have to know what kind of errors your users and customers are experiencing. Many users of trial software won’t get in touch with you to report any errors. Instead, they will just uninstall your application and test a competing product. To make error reporting for end-users easier and more useful to you, you should use automated error and exception reporting techniques. When an unhandled exception occurs, your application should show a friendly dialog offering the user to send an error report back to the developer. Error reports should contain all kind of information to help you identify the problem, including error messages, call stacks, version numbers and log files.

6. Customer Feedback

Similar to error reporting, you should make giving feedback as easy as possible for your users and customers. In SmartInspect, for example, we have buttons in the menu and toolbars to send feedback and questions. You can also use a short (optional) survey when a user uninstalls your application. This survey should only have a few questions and besides other things ask why the user uninstalled your software. If a lot of users report that they uninstalled your software because of stability problems, you will know that your application isn’t as high-quality as you have thought.

7. Use Proven Code

You should build the core functionality and main features of your applications yourself, because only then are you able to easily and quickly modify and improve it. But for many other parts you can reuse existing and proven code. It will take you years to build a stable, easy-to-use and feature complete reporting engine or setup builder, for example. Often times it’s better to use proven existing code, either from internal libraries, third-party companies or open source solutions if the license permits this.

8. Dedicated Testers

If possible, you should have dedicated testers in your organization for quality assurance. In fact, you should have lots of them. For simple standard applications, one tester per developer is a good rule of thumb. For applications that are complicated and time-consuming to test, two or more testers per developer are needed. Many small organizations cannot afford dedicated testers. If this is the case, developers should test each others’ code. It’s important that others test your code and functionality, because general wisdom says that developers do a really bad job testing software that they wrote themselves.

9. Virtual Machines

To test your software on as many different environments and operating systems as possible, you should use virtual machines with tools like VMware, Virtual PC or other available virtualization software. Besides allowing you to test your software on all kinds of configurations, you will save tons of time because you can easily copy, share and reset the virtual machines. It’s a good idea to create many different standard images for all the operating systems you regular test on and put them on a file server. When you need a specific configuration to test something, you can then start with one of your base images without installing the operating system, drivers and required software and so on.

10. Write a Specification

Many bugs are caused by badly designed class hierarchies, inaccurate interfaces, wrongly understood requirements and the therefore required workarounds. That’s why an experienced developer or architect should write a specification with all the collected requirements and technical implementation details before writing the first line of code. But as always, requirements change during the lifetime of a software application. That’s why it’s important to keep the specification up-to-date and plan the architecture changes for any new or altered requirements.

11. Use a Good Debugger

If you use an IDE like Visual Studio, Eclipse or Delphi, you already have access to a powerful debugger that you should use. But with many development environments and development platforms like PHP, Windows Scripting, Python and Ruby, many developers aren’t using a debugger. In those scripting environments, developers often try to squish bugs by try and error, changing code parts, adding a few print statements and so on. This is not only a very cumbersome and time-consuming way of identifying and solving bugs, it’s also very dangerous if you don’t fully understand your code and are able to step through it with a debugger. Do yourself a favor and get a good debugger for your development platform (and there are debuggers for almost everything).

12. Debug and Strict Options

Many development environments allow you to enable special debugging options like range checking, overflow checking and memory corruption checking. Such options should be enabled during development and sometimes even during quality assurance to identify hard to find bugs. Many script languages like Perl or PHP on the other hand allow you to enable certain rules and warnings that will force you to declare variables before using them. This is especially useful if a script language is case-sensitive and it’s easy to make typos.

As I already said, these tips won’t make your software magically bug-free, but they allow you to make your software much more stable, reliable and usable if you put the work into it. And on top of it, it will make you a better developer, too.

If you read DelphiFeeds.com or some of the existing Delphi blogs regularly, you already know the following article. If you haven’t seen it yet and use Delphi, this article is highly recommended:

Creating Windows Vista Ready Applications with Delphi

The article describes some code changes to make Delphi applications take advantage of the new Windows Vista features like the new open dialog, window preview in the taskbar and the new task dialogs. Although these tweaks make Delphi applications more Vista compliant, there is actually surprisingly little to do to make Delphi applications work on Microsoft’s new OS.

Joel Spolsky laid out the Joel Test back in 2000 as a highly irresponsible, sloppy test to rate the quality of a software team as he calls it himself. Being a MicroISV, I didn’t expect us to rate that high on the test as some of the “rules” are obviously more appropriate for bigger teams. But see below for our rating.

1. Do you use source control?
We have been using a source control system from day one and wouldn’t develop even the most simple program without it. It’s just so convenient to have backups of every single version we ever checked into the source control system. Another important feature for us are branches. When we have to fix a bug in the currently released version and when we made changes to our code that we don’t want to ship right now, we create a new branch and fix the bug in it. We use Subversion as our source control tool and although it could be faster, it’s the best source control system I ever used.

2. Can you make a build in one step?
As Tobias outlined in the Explaining our build system blog posting, we use Cygwin and Makefiles for our build setup. We can make a build in one single step by executing the main Makefile. The scripts do everything from getting the sources, building the applications, help files, libraries, setups and so on. It has been a great timesaver for us.

3. Do you make daily builds?
We don’t have scheduled daily builds as it doesn’t really make sense for us at this stage. We start builds by hand when we check in some bigger changes into the source control system. But since we have days without a single source code change, we don’t need to have the build machine running 24/7. Besides, breaking the build is very rare as we are just 2 developers and the chances of breaking something is much smaller.

4. Do you have a bug database?
We use Trac as our bug database (and wiki). So far it’s been okay but it could be better. One thing I’m missing in Trac is a hierarchical overview of projects, bugs and feature requests (we had that in our home-grown bug database). Since our home-grown bug database was desktop based and we needed something web-enabled, we switched to Trac. We haven’t switched to something else because Trac has such a great Subversion integration and a built-in wiki and we haven’t found a good alternative for it yet.

5. Do you fix bugs before writing new code?
Most of the times we do fix bugs before writing new code. But there are some situations where this is not true. Take Windows Vista, for example. We tested SmartInspect on Vista and fixed most of the problems immediately. For some problems we decided to wait for later RC versions or the final Vista version as we aren’t sure if the problems are bugs of Vista or of SmartInspect. So in general I would say that we adhere to this rule but I don’t think this rule should be enforced strictly for every case.

6. Do you have an up-to-date schedule?
We do have an up-to-date schedule and are very strict about keeping SmartInspect in a ready-to-ship state. So if we have to release a new version of SmartInspect, we can do so pretty quickly. We set us milestones with planned features and release dates and try to stay close to the schedule. We have been pretty bad about this with SmartInspect 1.0, but improved considerable since we released the first version.

7. Do you have a spec?
Strictly speaking, we have to say ‘no’ to this one. We do talk a lot about planned features, their implementation and the best design. We also write down use cases and user stories when we plan a new release. But we don’t write 50-page documents with detailed discussions about every single feature that we want to put into a new release and I doubt that it would be worth it. We do write small specs about planned future products when we find a good new idea and want to preserve it for the future, but we don’t have specs for new versions of SmartInspect.

8. Do programmers have quiet working conditions?
I’m happy to say that this one is true for us. As we are just two developers and both of us have a quiet private office, it’s pretty easy to confirm this.

9. Do you use the best tools money can buy?
I would say ‘yes’ on this one. We have multiple monitors, good desks and good chairs, all the software that we need and up-to-date machines. We joined the Empower Program, for example, to get all the operating systems for testing and production usage that we need. We also have other not-so-cheap tools that make it easier for us to generate the SmartInspect library documentation which saves us a lot of time.

10. Do you have testers?
We obviously don’t have any dedicated testers but we compensate this by having a huge number of automated test cases for the SmartInspect libraries and comprehensive test plans. We execute the test cases and test plans on a regular basis and keep the bug count surprisingly low (our customers confirm this).

11. Do new candidates write code during their interview?
As we haven’t interviewed any candidates, this one doesn’t really apply to us. I guess this one doesn’t apply to most of the MicroISVs out there and is more appropriate for bigger teams.

12. Do you do hallway usability testing?
We did quick usability test of SmartInspect in the past and plan on doing it in the future. It has helped us a lot and we changed some of the features and changed default settings after seeing people having problems with the GUI. One of the things that the usability testing made us realize is that many people have problems with docking windows. That’s why we disabled docking in the SmartInspect Console by default and added a Reset Docking feature to undo any docking with one click.

All in all we rate 8 out of 12 on Joel’s Test with 2-3 rules not really appropriate for a very small ISV like us. That’s not too bad I guess and we are pretty happy about our development system. How do you rate on the test with your MicroISV?

Most people probably know this already, but it was new to me: the MSDN search is now powered by Windows Live (aka MSN Search). My Microsoft ISV buddy told me this (Hi K. :-)) and he is right about the increased speed and search quality.

I tried some search terms and got much better results than I remember getting from MSDN before (I have been using Google to search the MSDN lately because the old MSDN search wasn’t that great).

The new MSDN search is greatly appreciated, because contrary to the past, Google doesn’t list MSDN pages as the first result for Windows API searches anymore.