It seem like every development team I work with seems to have a big group of the team not understanding what the role of developer really entails. I am even more and more surprised to find how many developers out there lack hardware knowledge, or even have a basic understanding of how the operating system works. I have always maintained that a developer, no matter what development you do, needs to understanding the basics of computers. The importance of understanding how your machine works, is as important as a soldier knowing how to clean and pull apart his weapon. I often sit in amazement and watch how developers find the most creative workarounds for a problem, rather then spending time actually solving it, or even doing some research on how to solve a problem. The latter being another interesting topic.

To explain my statement let’s have a look at a past scenario. About 2 years ago I was involved in the development of an asset management system for a major motor manufacturer. The requirements of the project was actually very straight forward and simple. The company had a team of individuals that would use handheld scanners to scan barcodes placed on every item purchased by the company. The data then needs to be uploaded to a central server where it is checked and then pushed into a flat file to be imported into the accounting system. The overall process sounds simple, but at the time I joined the project, it had already been in development for 2 years, and in this time the team responsible for the project could not get the system working in a testing environment.

Recruiting the services of a industry export on handheld development we started pulling apart the non-working solution to try and find a way to make the system work. The original solution was build using Windows Mobile and Sql Server 2005. The implementation however was creating various complicated problems on both the handheld devices, as well as the management module. The approach taken by the original team was to build the project from the synchronization module and then fit the rest of the system in around it. The team doing the development was offsite, and had not at any point seen the actual environment, until the testing environment was built. The synchronization failed at every step and your analysis found that this was caused by a few unique issues.

Handheld Connection Failures. The handheld devices where using Sql Mobile Replication to transfer data between the main database and the handheld devices. However the only way to connect was via ActiveSync and the asset table contained almost 3000 rows at the time. The devices continuously lost connection, often because of bandwidth issues. At no point did the team realise that WAN setup used by the customer is overly used and therefore never considered the impact on the system. The solution we decided to go with was a straight forward flat file Xml document copied from a client host to the handheld, with the client host connecting to a .Net remoting server running on the database server, minimizing the traffic on the line considerably, and ensuring that the process of file copies could be monitored locally, as well as supporting multiple client hosts.

Handheld Memory Failures. The second problem was related to the handheld devices. The original solution required Sql Server Mobile as well as Compact Framework 2.0. However these two prerequisites held a footprint of about 23MB combined. The actual devices only had 32MB of memory available and the test unit used by the original team was double. The software was also extremely complicated to deploy, and with 6 or more physical devices to manage it became a problem for the IT team. The solution we implemented automated the deployment of the actual software using CAB files and the client host application which was written in C# and Windows Forms. It also wrapped ActiveSync and allowed for complete management of the device from the client desktop. The last implementation we did was to develop the application in Compact Framework 1.0 using Sql Server CE, which reduced the footprint to about 12MB on the devices.

Handheld Search Speed. From scanning an asset to find the relevant record in the original solution took approximately 3 minutes. This was due to the table structure on the device as well as a dependency on a third party scanner interface. The first problem we resolved in 2 ways. Firstly we designed a smaller table set for the devices, only containing the information required, and secondly we built proper indexes on the devices. We also changed the import to run on the device directly, allowing the scan team to move between areas while the devices updated. The latter problem was resolved by implementing an API talking directly to the scanner, which reduced the overall scan speed to 30’s for 10 000 rows on the devices, the absolute maximum a single device would hold.

Server Connectivity. The last issue was that connections to the server required massive firewall changes, which caused policy issues for the customer. The new implementation provided a configurable interface for the remoting service which allowed the IT team to specify the ports the service was made available on.

During the development process, we became aware of these problems as we tested. However instead of making it part of the specification and forcing the client to accept it out of the box we built solution to reduce the impact of these problems, or to completely illuminate them from the system. The end result was impressive. We redeveloped the project from scratch in under 3 weeks, tested and deployed in less then 2 and had a happy client, who has since had 2 significant upgrades done to the system and implemented new handheld devices, which worked out of the box. Knowledge of network architecture, hardware and even IT policies and procedures enabled the team to know what to look for and how to potentially deal with the problems experienced during testing and development, and allowed for a very successful, and powerful solution implementation.

The question therefore is, do you really understand the problem? Or do you just find a workaround that in the end is taking up more time then researching and solving the original problem?