1. Introduction

In this tutorial, we’ll learn about the meaning of the term ad-hoc in different contexts and then focus on ad-hoc programming.

2. Ad-hoc

Generally, we can say that ad-hoc thinking implies deciding our actions on the fly and considering only a particular situation. The opposite is systematic thinking which refers to a structured way of thinking about a problem after considering all its aspects.

For instance, in networking, an ad-hoc network is a system of network elements that are constructed on the fly based on current needs without any prior planning:

Ad-hoc Network

Similarly, in corporate governance, we establish ad-hoc committees to deal with specific and stand-alone problems that don’t fit into the current governance structure.

Moving further, in military setup, we create ad-hoc units in extremely unpredictable situations. Such situations demand quick actions and we need a high degree of cooperation between different units.

3. Ad-hoc Programming

Ad-hoc programming means writing code in an unplanned way and for a particular purpose only.

There, the focus is on quick delivery and solving a specific problem rather than detailed planning and developing a generic tool for solving problem instances of the given class.

3.1. Ad-hoc Database Queries

An example of an ad-hoc database query is a single atomic query with hard-coded search values. So, it has no parameters and isn’t a part of any stored procedure.

For example, let’s say we store the employee data in the table employee:

Rendered by QuickLaTeX.com

An ad-hoc query to get all the data on the employee with id 101 is:

select * from employee where id=101;

A non-ad-hoc approach would be to create a stored procedure to which we supply the employee id as a parameter. As a result, we get a tool we can use for other ids:

select * from employee where id=@id;

3.2. Ad-hoc Coding

Ad-hoc coding means the developer isn’t developing the solution by following a software design plan but jumps straight away to coding without analyzing the problem at hand. Usually, that results in an easy-to-implement solution that is inefficient and covers only a subset of possible input cases.

For instance, let’s say we want to determine if two words are anagrams. By definition, an anagram is a word or a phrase whose letters we can rearrange to obtain another word or a phrase (like ‘break’ and ‘baker’).

Let’s say word_1 and word_2 have n characters. Now, an ad-hoc way of solving this is to iterate over all characters of word_1, comparing each character with all characters of word_2. If all the letters of word_1 match those of word_2, and vice versa, the two words are anagrams of one another:

algorithm CheckAnagramsAdhoc(word1, word2, n):
    // INPUT
    //     word1, word2 = the words to process
    //     n = the length of word1 and word2
    // OUTPUT
    //     true if the words are anagrams, false otherwise

    if each character of word1 is in word2:
        if each character of word2 is in word1:
            return true
            return false

However, we that has the time complexity of O(n^2).

If we analyzed the problem first, we’d conclude that we can sort the characters in both words and compare them one by one until we match them all or find a character we can’t match. Thar way, we can solve the problem in O(n \log n) time:

algorithm CheckAnagramsAlgorithmic(word1, word2, n):
    // INPUT
    //     word1, word2 = the words to process
    //     n = the length of word1 and word2
    // OUTPUT
    //     true if the words are anagrams, false otherwise

    sort word1
    sort word2
    if word1 = word2:
        // sorted strings match so the words are anagrams
        return true
        // sorted strings don't match so the words aren't anagrams
        return false

3.3. Ad-hoc Testing

Ad-hoc testing is informal, unstructured and shortcut software testing wherein we randomly test part of any software system. Here, we also don’t follow any framework to create test cases:

Ad-hoc Testing

We usually do this when we don’t have a lot of time for testing.

4. When to Use Ad-hoc Programming

We can use an ad-hoc approach for small problems that have changing requirements and for which we need quick solutions. So, to reduce the time to production, we start coding without analysis and a plan.

Similarly, if we’re considering several strategies, we can implement and test each in an ad-hoc manner. Based on the results, we choose one to implement and test systematically.

For instance, let’s say we’re evaluating different methods to convert our search microservice from synchronous to asynchronous modes. Now, we want it to carry search in the background and not block on it. We can achieve that in many ways such as using thread pools, message queues, or subscriber-publisher models. Instead of developing each alternative, we can adopt ad-hoc programming and quickly write a small proof-of-concept code for each approach. Afterward, we do limited testing and choose the best-performing option.

5. Conclusion

In this article, we have gone through the ad-hoc programming approach in detail. It’s an improvised or impromptu way of solving problems. In essence, ad-hoc coding brings quick results but the code is usually inefficient and focused only on the problem instance at hand, so it doesn’t give us generic and reusable solutions.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.