Category Archives: productivity

CoverageValidator v3

The nice folk at Software Verification have done a major new release of Coverage Validator, and the new version fixes many of the issues I noted in a previous post. In particular:

  • The instrumentation can use breakpoint functionality to get better line coverage on builds with debug information enabled.
  • Previous sessions can be automatically merged into new sessions.
  • The default colour scheme has been toned down.
  • The flashing that happened when you resized the source window has gone.
  • It is now possible to mark sections of code not to be instrumented. I haven’t had time to try this yet, as it was only introduced in v3.0.4. But it should be very useful as currently I have a lot of defensive code that should never be reached (see below). Instrumenting this code skews the coverage stats and makes it harder to spot lines that should have been executed, but weren’t.

There are still a few issues:

  • I had problems trying to instrument release versions of my code.
  • It still fails to instrument some lines (but not many).
  • I had a couple of crashes during testing that don’t seem to have been caused by my software (although I can’t prove that).

But the technical support has been very responsive and new versions are released fairly frequently. Overall version 3 is a major improvement to a very useful tool. Certainly it helped me find a few bugs during the testing of version 4 of Perfect Table Plan on Windows. I just wish there was something comparable for MacOSX.

Choosing a development ‘stack’ for Windows desktop applications

beauty_parade.jpgI have have heard plenty of people saying that desktop software is dead and that all future development will be done for the web. From my perspective, as both a buyer and seller of software, I think they are wrong. In fact, of the thousands of pounds I have spent on software in the last three years, I would guess that well over 90% of it was spent on software that runs outside the browser. The capabilities of web based applications have improved a lot in recent years, but they still have a long way to go to match a custom built native application once you move beyond CRUD applications. I don’t expect to be running Visual Studio, PhotoShop or VMWare (amongst others) inside the browser any time soon. The only way I see web apps approaching the flexibility and performance of desktop apps is for the browser to become as complicated as an OS, negating the key reason for having a browser in the first place. To me it seems more likely that desktop apps will embed a browser and use more and more web protocols, resulting in hybrid native+web apps that offer the best of both worlds.

So, if Windows desktop apps aren’t going away any time soon, what language/libraries/tools should we use to develop them? It is clear that Microsoft would like us to use a .Net development environment, such as C#. But I question the wisdom of anyone selling downloadable off-the-shelf software based on .Net [1]. The penetration of .Net is less than impressive, especially for the more recent versions. From stats published by SteG on a recent BOS post (only IE users counted):

No .Net: 28.12%
>= .Net 1.0: 71.88%
>= .Net 1.1: 69.29%
>= .Net 2.0: 46.07%
>= .Net 3.0: 18.66%
>= .Net 3.5: 0.99%

Consequently deploying your app may require a framework update. The new .Net 3.5 framework comes with a 2.7 MB installer, but this is only a stub that downloads the frameworks required. The full set of frameworks weighs in at eye watering 197 MB. To find out how much the stub really downloads Giorgio installed .Net 3.5 onto a Windows 2003 VM with only .Net 1.0 & 1.1. The result: 67 MB. That is still a large download for most people, especially if your .Net 3.5 software is only a small utility. It is out of the question if you don’t have broadband. Microsoft no doubt justify this by saying that the majority of PCs will have .Net 3.5 pre-installed by the year X. Unfortunately by the year X Microsoft will probably be pushing .Net 5.5 and I dread to think how big that will be.

I have heard a lot of people touting the productivity benefits of C# and .Net, but the huge framework downloads can only be a major hurdle for customers, especially for B2C apps. You also have issues protecting your byte code from prying eyes, and you can pretty much forget cross-platform development. So I think I will stick to writing native apps in C++ for Windows for the foreseeable future.

There is no clear leader amongst the development ‘stacks’ (languages+libraries+tools) for native Win32 development at present. Those that spring to mind include:

  • Delphi – Lots of devoted fans, but will CodeGear even be here tomorrow?
  • VB6 – Abandoned and unloved by Microsoft.
  • Java – You have to have a Java Run Time installed, and questions still remain about the native look and feel of Java GUIs.
  • C++/MFC – Ugly ugly ugly. There is also the worry that it will be ‘deprecated’ by Microsoft.
  • C++/Qt – My personal favourite, but expensive and C++ is hardly an easy-to-use language. The future of Qt is also less certain after the Nokia acquisition.

Plus some others I know even less about, including: RealBasic and C++/WxWidgets. They all have their down sides. It is a tough choice. Perhaps that is why some Windows developers are defecting to Mac, where there is really only one game in town (Objective-C/Cocoa).

I don’t even claim that the opinions I express here are accurate or up-to-date. How could they be? If I kept up-to-date on all the leading Win32 development stacks I wouldn’t have any time left to write software. Of the stacks listed I have only used C++/MFC and C++/Qt in anger and my MFC experience (shudder) was quite a few years ago.

Given that one person can’t realistically hope to evaluate all the alternatives in any depth, we have to rely on our particular requirements (do we need to support cross platform?), hearsay, prejudice and which language we are most familiar with to narrow it down to a realistic number to evaluate. Two perhaps. And once we have chosen a stack and become familiar with it we are going to be loathe to start anew with another stack. Certainly it would take a lot for me to move away from C++/Qt, in which I have a huge amount of time invested, to a completely new stack.

Which Windows development stack are you using? Why? Have I maligned it unfairly above?

[1] Bespoke software is a different story. If you have limited deployment of the software and can dictate the end-user environment then the big download is much less of an issue.

Coverage Validator

coverage_validator.pngThe sink is full of washing, I am wearing odd socks and I haven’t been out of the house in days. It must be time to put out that new release. But how can I be sure my testing hasn’t missed a hideously embarrassing bug? Maybe I introduced a major bug when I made that ‘cosmetic’ change at 2am?

In an ideal world I would just run a comprehensive automated regression test suite. Unfortunately it is difficult to automate graphical user interface (GUI) testing and the majority of lines of code in most applications are GUI. I estimate that the code for my own table planner software is at least 75% GUI code (not including generated code, which would push it even higher).

So I try to manually execute every line of my application before I release it. If I have to make any changes to the code, I start over again. This is very dull, but at least I have a tool to help me: Coverage Validator. Coverage Validator instruments code and shows, in real time, which lines have been executed. Click a few buttons on your application and watch the executed lines of code change colour from pink to yellow. Execute every line in the file and all the lines change colour to cyan. No recompilation or relinking is required and it doesn’t slow down the tested application too much. This real-time feedback is incredibly powerful for testing.


Unfortunately it also has a lot of shortcomings:

  • The usability isn’t great. There is a confusing plethora of options for instrumenting your code that I would rather not have to know about.
  • It isn’t able to ‘hook’ (instrument) all the lines of code. Whole blocks get missed out for reasons I don’t fully understand. Single line branches are particularly likely to be missed.
  • The GUI isn’t great. For example, the display flashes horribly if you resize it.
  • The automatic results merging is just plain weird. At the end of a session it can merge your coverage results into a previous session. This information isn’t much use to me at the end of a session. I want to merge previous results at the start of a session so I know which lines I haven’t tested.
  • The GUI is quite ugly. They really need to update those tired old icons.

However being able to see line coverage information in real time is just so incredibly useful that I am prepared to put up with the many shortcomings. I just run my application alongside Coverage Validator and, file-by-file and function-by-function, I try to turn the lines of code yellow (or, better still, cyan). Every time I have used Coverage Validator I have found at least one potentially embarrassing bug that I hadn’t discovered by any other means. The support has also been responsive. It is just a pity about the flaws, without them this would be a ‘killer app’ for testing.

Coverage Validator works with C++, Delphi and VB on Windows NT4, 2000, 2003 and XP[1]. A single licence costs $199. A free 30-day evaluation licence is available.

[1]I am using it on Vista currently, and it seems to work fine.


codekanaI don’t remember when or where I first saw an editor with syntax highlighting. But I do remember that I was ‘blown away’ by it. It was immediately obvious that it was going to make code easier to understand and syntax errors easier to spot. I would now hate to have to program without it. So I was interested to try version 1.1of CodeKana, a recently released C/C++/C# syntax highlighting add-in for Visual Studio.

Codekana features include:

  • Finer grained syntax highlighting than VS2005 provides.
  • Highlighting of non-matching brackets and braces as you type.
  • Easy switching between header and body files.

In the code below Codekana colours the if/else/while blocks differently and visually pairs the braces:

syntax highlighting

I have only been using Codekana a few hours, but I am already impressed. I find the ability to quickly switch between C++ header and body files particularly useful. VS2005 only appears to allows switching body to header, not header to body (doh!). You need the dexterity of a concert pianist for the default Codekana keyboard shortcut (Ctrl-Shift-Alt-O), but it can be customised. I changed it to Ctrl+. (dot) .

Codekana also has other features, such as the ability to zoom in/out on code. This is quite ‘cool’, but I’m not sure yet whether it will be of much use. Time will tell.

I am new to VS2005 and I have yet to try out other add-ins, such as Visual Assist, but Codekana certainly seems to have a lot of potential and is excellent value at $39. I look forward to seeing what other features get added in future versions. Find out more and download the free trial here.

Disclosure: The author of Codekana is a JoS regular who I have corresponded with in the past and was kind enough to send me a complimentary licence.

Programming in flares

waves off HawaiiFashion is such a ridiculous business. Every year anorexic clothes horses strut up and down modelling ridiculous clothes no-one is ever going to wear. Hemlines go up or down. Various baubles are ‘in’ or ‘out’. Grey is the new black. We geeks are above all that. Comfortable in our jeans, bad haircuts and nerdily sloganed black t-shirts we know that #000000 != #0c0c0c . We care not a jot for fads and fashions. Or do we?

Actually, I think software development follows its own fads and fashions, just as slavishly as any Gucci-clad fashionista. Here are a few past and present software development ‘fashions’ that spring to mind:

  • 3GLs
  • 4GLs
  • methodologies (SSADM, Yourdon etc)
  • CASE tools
  • object orientation
  • UML
  • Java
  • XML
  • extreme programming/agile methods
  • Ruby on Rails

While all of these ideas contain something useful, they never turn out to be the panacea we were promised. Consequently they follow (or, I predict, will follow) an all-to-familiar boom and bust cycle:

  1. potential – The technology appears to have some promise.
  2. hype – The technology is wildly over-hyped. Massive and unrealistic increases in productivity are touted.
  3. hysteria – Lots of books and magazine articles are written. Developers worry their careers will suffer if they don’t learn the new technology, and soon.
  4. backlash – The reality falls far short of expectations and the whole worth of the technology is called into question. But actually the technology is improving as it matures.
  5. realism – Expectations settle down to more realistic levels and the best elements of the technology are absorbed into mainstream practice.

We can visualise the cycle in a simple graph:


Java is a good example of this cycle. It started its life as Oak, a language for set-top boxes. Renamed to the more catchy Java and pushed by Sun as a write-once run-anywhere language it soon passed from hype to hysteria on a wave of coffee related puns. Everything would soon be written in Java we were told in endless gushing articles. The performance issues would be sorted out in the next release. Corel were rewriting their office suite in Java. Netscape were rewriting their browser in Java. C++ was finished. Sun’s stock rose meteorically.

In fact Java apps of the time were ugly and slow and the cross-platform capabilities turned out to be problematic. Write-once run anywhere became write-once, test everywhere. Java Corel office was rapidly abandoned when the beta was found to be completely unusable (I tried it myself, it was a joke). Netscape’s attempts to produce a web browser in Java also failed. The backlash began. In actual fact Java is now not much slower than C++ for many applications. But the Java zealots cried wolf so many times in the past that few people believe them any more. Finally we are reaching a realistic understanding of the strengths and limitations of Java, but most of us lost interest in Java a long time ago and are too busy pursuing the next ‘great thing’.

What is the latest fad? Agile methods is certainly a contender. Agile methods are ‘lightweight’ methodologies, a backlash against ‘heavyweight’ methodologies, such as Rational unified Method and SSADM. If you search for “agile” in ‘Books>Computers & Internet’ on you get 2,964 matches. How can so much possibly be written about a ‘lightweight’ approach? A recent C/C++ conference I went included no less than 6 talks with ‘agile’ in the title (and a couple more on the related topics of ‘lean development’ and ‘scrum’). No doubt there are whole conferences about agile methods. While I don’t doubt that an agile approach contains useful ideas, I very much doubt that it is a one-size-fits-all, ‘one true way’ to develop software. But you would be forgiven for thinking that it was if you listened to some of the agile zealots (especially the ‘extreme programming’ wing of the agile church).

Boom and bust is a painful, expensive and pathological way to adopt new ideas and technologies. Why can’t we take a more measured and mature approach? Fred Brooks warned us over 30 years ago that software development is hard and it probably always will be. But the message appears still not to have sunk in. We are still looking for for that mythical silver bullet. The problem is partly caused by many developers having a lack of perspective. They are so focused on the minutiae of programming and the latest cool technologies that they just can’t see the bigger picture. Because they don’t understand the past they are condemned to repeat it (to paraphrase Santayana).

Much of the cycle is also driven by self-interest. The pundits make a very nice living selling books, consultancy and training. The journalists get something new to write about. The developers and team leads get to do ‘cool’ stuff and add some exciting new acronyms to their CVs. The vendors are happy to sell expensive new tools. Unfortunately the employers, shareholders and customers end up with late, over-budget and buggy software because the developers choose a cool new, bleeding-edge technology over something more mature and well understood. But it is too late by the time the problems become apparent.

Development environments are now vast ecosystems of languages, libraries and tools. Surely it is better to take the time to master one of these environments and understand its strengths and weaknesses, than to be continually chasing the latest fashion and never master anything. Better the devil you know than the devil you don’t. I am not against progress and I certainly don’t think we should try to use the same tool for every job. Many of the technologies I have listed above led to major steps forward, even if they didn’t live up to the initial hype. But software development should be a means to an end and we should never be so wrapped up in the technology that we lose sight of that. Professional developers should pay less attention to the latest fashions and focus more on solving problems for their customers. An experienced C programmer is almost certainly more productive than an inexperienced Ruby programmer. Wear your flares with pride.

Dealing with embedded GIF spam

embedded GIF SPAMSpam and phishing emails can be a huge drain on productivity for an Internet based business. I use Mozilla Thunderbird and I find the spam filtering works tolerably well. Most of the incoming spam is quietly siphoned off into a ‘Junk’ folder and there appear to be very few false positives. I supplement this with a message filter to move all emails purporting to be from or (99% of which are phishing emails) to a ‘Suspicious’ folder, which I check from time to time. But I still get lots of spam with embedded GIF images, which Thunderbird’s spam filter seems to be powerless to handle.

Mostly these are ‘pump and dump’ stock tips, but some of them are for viagra, cialis etc. Some of the spammers even helpfully include images of the body parts targeted by these medications. After a quick Google I found out how to set up a message filter for embedded GIFs on Uzik’s blog. Any email with an embedded GIF that comes from someone I don’t know now gets sent to my ‘Suspicious’ folder. Thanks Uzik! A similar approach should work in many other email clients.

Thunderbird embedded GIF rule

a rule for embedded GIFs (click to enlarge), see Uzik’s blog for more details

Note that some legitimate emails may have embedded GIFs as background images. While this practice is highly questionable you won’t want to lose these emails, so you should check your ‘Suspicious’ folder from time to time.

Of course this is only partial solution. The only real solution is to stop the spam in the first place. I say cut off their goolies.