The Pseudo Science of Computer Software Bugs – Part 1

Every developer out there tries to write perfect computer software code.

Well, if they are not trying to write perfect code, they should be.

So, what is perfect code? One would hope it is code that functions as it was designed to. Even better if there are actual documented specifications and the software looks and behaves as described in the specifications.

There are plenty of publications about designing and writing software and about best practices for development processes and these articles will never be up there with those!

The content of this series of articles is based on my experience developing software over the last 37 years or so. To help you understand my perspective, here is some background information:

In 1980, when I was 12 years old and lived in the UK, I played with my neighbour’s Sinclair ZX-80 and I was hooked. After moving to Australia, my step-father brought home a Commodore PET and later an Apple //e. Once I really started learning how to program in Applesoft (BASIC) and Motorola 6502 (Assembly), the direction my life would take was locked in. I later bought that Apple //e and was writing and selling business software while still at school.

Then I saved up and spent all my money to buy an Amiga 2000 (with IBM PC Bridgeboard) and started working with the Amiga’s GUI style OS and MS-DOS on the PC. While the Amiga was awesome as a games machine, I ended up doing more software development work on the PC. I worked with Microsoft QuickBasic and 8086 Assembly and continued writing custom software.

In 1989, I got a job writing software for the real estate conveyancing industry. I graduated to the third generation languages of dBXL with the QuickSilver compiler (not well known but better than the dBase III+ and Clipper compiler combination) and started working with databases running on CCI Concurrent DOS (later known as Multiuser DOS). I worked out database design theory because it made sense. Later, when I did a database design unit at university I learned that there were names for what I was already doing, like “Normalization”. I ended up buying the conveyancing software I developed from my employer and started selling and supporting it as my own business.

The final piece of the story was when I started working with Paul Templeman at Sequel Technology. Here is the logo, some of the GP old timers might remember this one.

While at Sequel Technology we were introduced to Great Plains Software and their new Dynamics 1.0 product. After reviewing the product, we liked what we saw but were not yet convinced to get involved with this first release.

In 1994, When Dynamics 2.0 was released, we signed up as partners and I learned Dexterity at the first training course to be run outside of Fargo, North Dakota USA. Kevin Kidder came to Melbourne, Australia for his first ever international trip and trained a number of Australian developers in Dexterity 2.04.

I have never looked back since then I expanded into Visual Basic for Applications and SQL Server and even dabbled with Visual Studio and Visual C# and Visual Basic.Net. From 1999, I worked for myself as Winthrop Dexterity Consultants for two years and then for Microsoft for 13.5 years. Leaving Microsoft in 2014, I restarted my business and rebranded as Winthrop Development Consultants.

Why the personal history lesson?

I wanted to provide some context of where I am coming from, including the fact that my background has always been working as a single developer without any formal software development training. I have been self-taught for almost all of languages and skills I learnt. There were not any computer specific courses available until the very end of my time at university.

In the next article, I will discuss my personal theories on “The Pseudo Science of Computer Software Bugs”.

David

This article was originally posted on http://www.winthropdc.com/blog.