A while ago I had a security company (whose name I will not mention - for now) install a burglar alarm system for my new home. As I was not technically clued up on the vast array of different options and choices one have with purchasing an alarm system, I made a grave mistake. I asked advise from the security company on what I should purchase.

My experiences thus far always pointed back to the one fact, that most security companies do not know anything more than what is written on the side print of the boxes the alarm system components get delivered in. Since I make a point of going on to the Internet before I purchase anything of value, I am usually clued up more than the sales people! In this case I did not consult the Internet since I could not really find useful information.

To come back to my opening statement, the reason I said I made a grave mistake is that they did an absolutely pathetic job. I will not go into all the details, just those most applicable. Firstly, nobody asked me in detail how my house is laid out, whether I need perimeter protection or not, explain the different kind of sensors etc. They assumed an 8-zone IDS system would suffice. I specifically asked for an outdoor sensor since I knew I wanted perimeter detection, so that was added to the list. In the end everything got installed but now I have several issues:

Maybe I am too headstrong, but I have found that QoS (Quality of Service) - in this country at least - is absolutely pathetic.

As an example, take my car. I took it in for a service about three weeks ago. For the service I mentioned that I experienced an intermittent vibration when the car is idling. They duly jotted this down and said they'll have a look (my car is still under guarantee). That afternoon (after I phoned them - they forgot to phone me) they informed me that they had to order some parts (cannot remember what exactly) since they did not have it in stock and that was causing the vibrations. As I am a quite understanding person, I accepted this and booked my car for the next week.

Come the following week, I took my car in and later that afternoon I received a call that it was ready and all fixed. Happy about this I drove through to Pretoria and picked up my car. I barely drove 10 meters when I immediately realised the window was not working anymore - at least the automatic mode where you push the button for a second and it keeps moving until it is either closed or open. I had to keep the button depressed. I took it back only to hear the technician make a comment about the window being like that when he worked on it this morning. So I asked him whether he implied I broke it? He just mumbled.

I just came across this article and was shocked - even though I knew this is how most people view software development. Look especially at this quote:

On the other hand, you could encourage your students to have a more polished approach within the language, suggesting not to use primitive types, and to use methods instead of operators wherever it's possible.

Out goes performance and resource consumption... It is completely ignored. Irrelevant. Why? Because our computers are so powerful. So why worry about performance and resource usage if our code takes 100ms to execute instead of 10ms, or uses 64bytes of memory instead of 4bytes? It saddens me to say, but I think we have lost a great generation of software developers somewhere during the past decade.....

Many times I find myself wondering about the future of the way we develop software currently. I guess if you ask different people their opinions you'll get just as many different views.

Back in the good old days we used to use punch cards to feed into the machine, from which the program is read and executed. Each time you want to execute a program, you have to load it using the punch cards again. Lateron came assembly language, where at least you could express yourself at the level of the CPU's opcodes, and save the programs for execution in an assembled, linked state called an executable application.

People used to build highly sophisticated systems using the archaic assembly language, under which operating systems, big parts of the original Windows NT kernel, etc. are examples.

One thing I am constantly fighting with while developing software systems, is the issue of when to do automated testing, and when not to. Some evangelists of automated testing procedures will try and convince you to always automate your testing.

I believe differently. Like everything in life, there should be a balance between using automated procedures and manual testing. Web based systems are growing at a very rapid pace, and this is a prime example of where a delicate balance is needed. Automating back end logic is much easier than automating front end logic (i.e. the GUI). This is simply because the user interface is not easily accessible using programmatic methods such as API's, services etc.

Most (clever) people adopted the coding style of separating business logic out of the UI, into a separate business layer. This eases automated testing dramatically, since now most of the functionality can be automated and only the thin UI layer needs to be tested manually.