The Code Whisperer

We all have days where we panic because of the amount of work we have or just things to sort out. Panic is a bad thing as it leads to mistakes being made and stress.

If you feel a sense of panic coming on STOP! Ploughing on head long will not help. Take a moment to reflect on the day’s task and write a list of the things to do. Part of the panic is because we are constantly juggling them in our mind, worried that we might forget. With a written list it may not seem as bad as we first thought.

Next prioritise the tasks. If you still feel panic when you look on the list, there’s too much on there for the time you have available, so start moving the lower priority tasks to a list for tomorrow until the list is manageable. Don’t forget if you complete today’s list by lunchtime you can always start on tomorrow’s tasks early - this is about low stress productivity not accurate prediction. There will be occasions where what’s on the list needs to be done before a deadline and can’t be moved to tomorrow; there may be a software release due (although I would worry about rushing this) or a plane to catch. Having identified what needs to be done means you can enlist help early on.

Les, a good friend of mine from Stoke-on-Trent, home of the tasty oat cake, is an extraordinary engineer and has been building vehicles for television programmes for a number of years. Often I would drop into his workshop early evening for a cup of tea and a chat and he would have a list of jobs as long as his arm. “MOT tomorrow, 9am” Les would say “not going to be ready though”. Les was quite happy to work through the night if it meant having the vehicle ready for the MOT, but if even that wasn’t enough, he would move the MOT by a day, go home at a reasonable time, get a good night’s sleep and crack on early next morning. In the cold light of day this seems obvious, but when we’re under pressure all we can think about is completing the tasks.

I’ve just received my copy of 5am & Already Behind by Dr Don Kennedy. From a quick skim it looks an interesting and useful book - I’ll let you know more when I’ve finished it.

Many years ago when VB3 was a current development environment, I had a contract with a electronic equipment manufacturer to produce software that integrated with their analogue to digital converter (ADC) and displayed real time data provided by the ADC.

It was a really interesting project, for me because there was a factory and R&D lab on site and an astonishing amount of diverse equipment including a 15 year old Commodore PET. Having spent the previous 6 years with the insurance and financial industries, working in an industry where you can touch the products they produce is a big bonus for me.

One of the big advantages of consulting and not specialising in a particular industry is that you get to see a wide range of practises and apply the good ones in other industries.

The production of electronic equipment is a precise art. Generally it works or it doesn’t, there isn’t the concept of “if you do this instead it will work”. It’s simply not that flexible. Clearly this was an ethos throughout the company, which resulted in a defect being raised during a code walk though because a comment was incorrect. Now as every dyed in the wool programmer will tell you, comments, and documentation, are unnecessary, nobody reads them, and if they are wrong, so what? Of course when the same programmer is making changes to an unknown part of the system they will complain if code comments and documentation is missing. The thing is that programmers have a passion for coding, and when presented with a task that isn’t coding they will do their utmost to avoid or minimise the interruption. It’s human nature: do I service the car or go shopping? Different people, different passions.

I was a bit shocked, this wasn’t a real defect, just an incorrect comment. Fortunately the chap in charge of the hardware took the time to explain why in the electronics industry documentation is so important. We shouldn’t allow incorrect or uninformative comments in the software development industry. It costs time and causes bugs to be released into the field. We’ll cover code reviews in a later posting, but if you are reviewing code as part of your development cycle (and I strongly believe you should) you must include comments in the review and get them corrected before the code is released.

Simply because it’s easier to design, code, test and modify, regardless of whether it’s a large application or a small database driven website.

The n-tier model has been around over 10 years now, and I think it’s a winner. The layout is straightforward to understand and it promotes the use of code reuse, which unlike some organisation’s view is not the same as copy and paste.

By isolating technology, changing it becomes very straightforward. In the early part of the 2000’s I re-architected a large Intranet system written in ASP/VBScript, VB6 and Sybase to a n-tier model. Suffering from over-engineering in places, the bulk of the processing took place in one VB6 dll. This caused a bit of a performance bottleneck and also proved difficult for more than two people to work on development at any one time. Despite these problems the application was an important part of the business and it’s inception made a visible positive difference to the bottom line.

So gradually the system was moved to a 5 tier system: presentation layer(ASP), business layer (VB6), data layer (VB6), data access layer (VB6) and the physical database (Sybase). Each release of the application had changes for the business and technological improvements. I often hear from software houses that they are driven by customer input and not by technology. This is a big mistake. Obviously you can’t just update a product to suit changes in technology, but not including technological enhancements creates a void in the application that eventually becomes impossible to fill. Each tier or layer kept the details of the next layer down from the layer above. For example the business layer had no knowledge of how the data was stored, it could have been in text files for all it knew, it just knew what methods in the data layer it needed to call to satisfy its data requirements.

Naturally there is a trade off. In the world of COM it’s often known as DLL hell, where incorrect entries in the registry cause the wrong DLLs to be called resulting in errors and catastrophic failures all over the place. In essence this is a deployment management issue and DLL hell is often the result of poor implementation procedures and a lack of understanding of COM. With the increased number of DLLs deployment becomes a bigger headache, particularly if you plan to deploy only those that have changed. Test, test and test the rollout - it’s the only way.

Having completed the re-architecture, changes in the business meant that Sybase needed to be swapped for Oracle. With our 5 tier model, the only parts of the application that knows how and where the data is stored is the data, data access layers and the physical database. The data layer was included as it contained some embedded SQL for performance purposes, but most database activity was via stored procedures, which although the stored procedure would need to change, the data layer wouldn’t as the data access layer provided a generic interface to a specific database.

The most painfully part of the change was conversion of the stored procedures. The rest went well and was completed quickly. Because of the modular architecture we were able to extract and work on just the layers needed, whilst the rest of the team continued adding new functionality required by the business.

One last example. Recently we developed an online diary system for a TV camera crew company. The idea is that people booking a crew select their dates from the website and this sends an SMS message to the camera company, who may be on a shoot away from the office. We need the information entered to be correct partly due to the cost of sending SMS messages, so there’s a lot of validation. Typically we would add the validation into the PHP page, with calls to standard validation methods, so it was all in one place. This time we decided to create a class with a validation method working from an array created by the page. We do this already for database access and to be frank I don’t know why we didn’t do this for validation before. What a joy! Testing was so much easier, we simply had a page that created an array with the values we wanted to test and then displayed the return values on the page. Traditional solid black box testing. Fantastic!

It took far too long for me to realise that software is a people business.

When I started commercial programming in 1981, computers were monoliths, locked in air-conditioned rooms, tended to by people in white coats and with applications you got what you got, with little in the way of choice or flexibility. Often systems were written to overcome hardware limitations, but did come in any colour you wanted, provided it was green on black.

Then came the PC, both IBM and Apple. You could have a computer in your house and it did stuff, but if it went wrong you were beholden to your mate who understood such things or paid people who tutted and uttered words that meant nothing to mere mortals.

And now the Internet, with applications galore. You can find software to do or manage just about anything and if you are lucky it doesn’t also install viruses or spyware. The personal computer is nearly personal.

Now computers are just about everywhere and control so much - I was amazed to find that the volume control on my friend’s Land Rover Discovery operated via software; surely a step too far?

Back to my original comment.

The vast majority of software is used by people. I know there are applications such as the depths of Windows and drivers, that few people outside of the developers see, but in general software is used by people. Despite attempts by an application called “The Last One” reported by Personal Computer World in 1981, software is designed and written by people. So why do we treat the process of software development like a production line? Why do we think that by adding developers, experienced in the chosen programming language, but with little knowledge of the application or the business it supports will rescue a late development?

As an industry I believe we need to move away from resource pools and looking at developers as resources that can be swapped around at a moment’s notice and towards development where an understanding and a passion of the business or past time the application is to enhance, is as important as the language and technology the software is developed using.

I’ve seen companies that take the time to immerse its design and development team in its business or the business it supports, and I’ve seen companies that don’t and the best software is produced by those that view a day spent away from a computer in the “field” is a day invested, not wasted.