“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”
Kernighan and Plauger
There’s supposedly a very similar quote attributed just to Kernighan, but I chose this one mentioned in this blog which also gave me a date of 1974.
There are two assertions in this statement, and I am pretty sure that the first is not true any more given that we have modern visual debuggers provided by tools such as Visual Studio. Debugging can be even be fun! But I think it is certainly fair to say that advanced debugging on a platform like Windows can easily extend complexity greatly. Continue reading
People sometimes claim that if a performance measure has not been recorded directly, then it is not possible to report on it. Need to know how long a batch job took to run? That’s ok – I have a table that tells me job run times. But if you need to know how much work a batch job did? We don’t record throughput, they say. This may be followed by a suggestion that they could add log messages or something like that. Continue reading
Baselining is used in IT to record some measurement(s) with a view to comparison later. If you know some statistic on one day – say for example the average CPU usage on a server, then you can measure the same data-point the next day and draw a comparison. It is often used so that you can measure the impact of some change or other, and assess its success.
Today, I want to talk about the importance of baselining with a counter-example – what can happen if you don’t baseline before making changes to a system; especially where those changes were intended to improve performance! Continue reading
In this Case Study we look at a number of changes in a key system. The client collected much of their income towards the end of the month when their customers got paid; these ‘Payment Processors’ were mission-critical. By concentrating on current needs, we were able to help improve the processors in a number of ways, and deliver the required changes quickly.
The problem 2008
Payment runs were taking so long that human intervention during the run could remove the need to take a payment at all. Locking data for the whole run was not an option, but we were able to increase resilience and reliability by double-checking all data before attempting a payment.
The result of these changes was that fewer customers were inconvenienced, and in addition, less time was spent by Call Center and Technical staff in resolving the issues that arose. Continue reading
The problem: A rapidly growing business needed to keep track of simple documents required for the Human Resources (HR) function. Additionally, tracking holiday entitlement and shift work were considered to be a valuable tool for future analysis of staffing levels, and so on. The client decided their needs were unlikely to be fulfilled by a package solution, and so a bespoke project was started. Continue reading
Many Years ago, our main consultant Nigel had an experience of development with a major London Borough which served as an education for his later work. Senior staff at the borough had requested development of a system for use in their contracts department that would serve several key needs:
- Businesses that wanted to work on council projects needed authorisation, and authorisation was to work on concurrent projects up to a limited financial value;
- As projects were created, authorised businesses in related areas (e.g. construction, education etc) were invited to tender for the project;
- Contracting firms that offered tenders would be entered in the system, and a winner would be chosen within a framework of rules that included limiting work to their financial limit and existing projects, and a random element.