Dragon after performance evaluation

How do “Code metrics” measure up? Ask Alfred.


Our strength is in embedded development and real-time systems. We dabble in other software but generally find our way back to bare metal development. Our prior work included developing tools under Unix, Linux and Microsoft's products. C and Unix have served us well for over thirty years; luckily Apple’s Mac OS X preserves much of that investment.

Apple’s Objective-C and the Cocoa frameworks were a steep learning-curve. They are also the only way to program the iPad. The iPad development tools at US$99 per annum were impressive. The Mac OS X based platform (fully loaded with development software on a US$999 Mac Mini server) is slightly more than a vanilla Windows PC without development software. Customers will find the low-cost capability difficult to ignore if attempting to integrate the iPad into their infrastructure. The Apple model of App verification and downloading does not favour custom automation projects, but there are a large number of tablets that can certainly support automation HMI panels.

We have done some C# work, but not enough to take on commecial projects. Our Objective-C interest faded when we could no longer connect to an iPad or iPhone during a software update. For intense string manipulation, the Objective-C calls are a huge learning curve compared to using vanilla C. We have been developing in C on Apple's Xcode, and will start with their Swift language in November. For the desktop, PHP, HTML, CSS and Javascript were studied enough to put this website together, but we don't actively seek web projects. We are currently working on a web framework which involves testing code generators and feature extraction for existing websites — much like PHP but written in C, so if you ever combine development and hosting on the same platform, that would be the way to go. (Prices for hosting in Australia are silly at the moment, but once tested, we might setup a server somewhere else).

Before starting a project, a few pages need to be put into place as to what is going to be written, how long the estimated time period (and hence the cost), plus a series of milestones so that each party can adjust to expectations along the way rather than squabble at the end. We are fully aware that we do not understand an end-user’s process or problem to the same extent as the end-user, and also that the end-user does not have the capability or time to write the software. Therefore, there has to be some flexibility in what software developers offer.

We favour the Principles behind the Agile Manifesto which considers working software as the primary measure of progress. Documentation will depend on the skills of the end-users, however, a system without documentation is useless; even the original implementors will need to go over some notes to resurrect a system in the event of a fire, flood or hardware failure.