By James Lawrence

In the world of agile development, estimating effort is a common practice. It involves predicting the amount of work required to complete a task, often quantified using story points. But does this practice actually benefit software teams, or does it create more obstacles than it removes?

Key Definitions

Before we go any further, it’s important to align on the meaning of the two terms below:

• Estimating effort helps teams plan the amount of work they can realistically complete within a given timeframe.
• Story points are numerical values assigned to tasks based on their complexity, often following the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, etc.). These numbers help teams gauge the relative effort required for different tasks.

When I first encountered these concepts, they seemed straightforward. However, I soon realised that estimation practices are highly subjective and can vary significantly between teams. This lead me to explore whether estimating effort is truly beneficial or if it might actually hinder team productivity; comparing the use of Story Points with the popular industry standard approach of #NoEstimates.

Using Story Points

In my role as a Delivery Manager for the Radio Fulfilment (aka gSchedule) team, I observed that our team lacked a consistent estimation process. The velocity (the number of story points committed vs. completed per sprint) appeared low due to inconsistent ticket sizing (despite a lot of work being done). This made it difficult to report on performance, confidently plan work going into sprints and create timelines.

To address this, I implemented a bucket system for estimation, where the team quickly discussed and sized all tickets into swim lanes. This method helped us calculate a more accurate velocity, averaging 56.4 points per sprint compared to the previous 9.4 points. The benefits were clear:

• Accurate Reporting: Consistent estimation enabled more accurate performance tracking.
• Credible Planning: With reliable data, we could commit to release dates with greater confidence.
• Enhanced Coordination: Our improved planning process facilitated better coordination with other teams, especially as we moved towards self-service.

The No Estimates Approach

Not all teams find value in estimating effort. The #NoEstimates movement, popularized by Woody Zuill, questions the purpose and effectiveness of traditional estimation methods. Here’s why some teams prefer not to estimate:

• Focus on Value: Shifting focus from estimating tasks to delivering customer value encourages prioritizing features based on their importance rather than complexity.
• Reduced Overhead: Estimating can be time-consuming and sometimes leads to unproductive disagreements within the team.
• Improved Collaboration: Less time spent on estimation means more time for collaboration and breaking down work into smaller, manageable tasks.

For instance, the gPO team works in Kanban and does not estimate effort. Instead, they track the average weekly number of tickets completed. This then allows them to monitor throughput by comparing the issues created versus resolved against their average.

Comparing the Two Approaches

Both techniques have pros and cons; their effectiveness can also depend on the team’s experience and working style.

Story Points

Pros:

• Versatile Planning: Allows teams to adjust their plans based on the specific work at hand.
• Momentum: Anecdotally, developers who size their own work can feel a greater sense of ownership and drive to meet delivery goals.

Cons:

• Time-Consuming: Estimation can lead to lengthy discussions and disagreements.
• Inconsistent Reference Points: Without regular reflection, the accuracy of estimates can vary over time.

No Estimates

Pros:

• More Time for Development: Developers spend less time on estimation and more on actual development.
• Agile Focus: Prioritises features based on user value rather than complexity.

Cons:

• Consistency and Experience in Story Splitting Required: Throughput tracking without estimating requires tickets to be of a similar size, so that the calculated average accurately represents the throughput. Stories must be broken down consistently to the same granular level eg. ~3 days or less to complete each Story.

Conclusion: Does Estimating Effort with Story Points Help or Hinder?

Based on my personal experience, I believe that estimating with Story Points is beneficial. Particularly for newer or changing teams that could benefit from a clear structure and more driven communication. For the Radio Fulfilment example, implementing a consistent estimation process improved visibility over our throughput and planning accuracy.

It’s important to note that, estimation practices should evolve with the team — it’s important to keep the technique relevant to current performance and needs.

Ultimately, the approach used to estimate effort depends on the team. It is a subjective technique and there isn’t a “correct” way of doing it. Teams should choose the method that best supports their workflow, ensuring they base their planning and reporting on accurate data. Regardless of the approach, tracking progress consistently and with team buy-in is crucial for delivering work with credibility.

To What Extent Is Estimating Effort Beneficial to Squads: Does It Help or Hinder Us? was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Ali Ammani

Welcome to the world of help desk, where technical expertise meets exceptional customer service. In today’s digital age, organisations heavily rely on help desks to provide timely assistance and efficiently resolve technical issues. This blog post will delve into the intricacies of help desk operations, exploring key applications such as Microsoft Azure, Active Directory, Endtune, and ServiceNow, while also highlighting the crucial role of people-help aspects such as logging tickets.

At the core of every help desk lies a robust ecosystem of applications designed to streamline support processes and enhance user experience. Microsoft Azure (a cloud computing service) empowers help desk teams like mine to manage resources, deploy applications, and monitor performance seamlessly. Active Directory plays a vital role in identity management, facilitating user authentication, access control, and group policy management. Endtune (a comprehensive endpoint management solution) enables help desk professionals to configure, monitor, and troubleshoot devices across the organisation. And ServiceNow (a leading IT service management platform) serves as the central hub for logging, tracking, and resolving support tickets, ensuring transparency and accountability in the resolution process.

Beyond the daily support of applications, the success of a help desk lies in its ability to provide compassionate and effective support to end-users. Logging tickets serves as the initial point of contact between users and help desk agents, laying the foundation for a seamless support journey. Whether it’s resolving technical issues, providing guidance on software usage, or offering troubleshooting tips, help desk agents play a pivotal role in addressing user concerns and restoring productivity. By fostering a culture of empathy, patience, and professionalism, help desk teams can cultivate trust and confidence among users, strengthening the organisation’s overall IT infrastructure.

To optimise help desk operations and deliver exceptional service, organisations can implement the following best practices:

- Proactive Monitoring: Leveraging tools like Microsoft Azure and Endtune to proactively monitor system performance, identify potential issues, and take pre-emptive action to prevent disruptions.

- Streamlined Ticket Management: Utilising ServiceNow to streamline ticket logging, assignment, and resolution processes, ensuring prompt response times and efficient case handling.

- Continuous Training: Investing in ongoing training and development programmes to equip help desk agents with the latest technical skills and customer service techniques, empowering them to deliver superior support experiences.

- Knowledge Base Management: Maintaining a comprehensive knowledge base containing troubleshooting guides, FAQs, and best practices, enabling help desk agents to access relevant information quickly and efficiently.

- Performance Metrics Tracking: Monitoring key performance indicators such as first-call resolution rate, average response time, and customer satisfaction scores to measure help desk effectiveness and identify areas for improvement.

In conclusion, the help desk serves as a cornerstone of support within a business, providing technical expertise and assistance to end-users across the board. By leveraging great applications, while prioritising the people-help aspects of support, organisations like Global can create a positive and productive network that impacts every employee and serves as a catalyst for success.

Help Desk: A Jack of All Trades was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Marlon Gaspar

Understanding Prompts in Generative AI

A prompt acts as the primary interface between the user and generative AI models. This interaction is predominantly textual; you instruct the model via text, and the model executes the task based on your directions. Essentially, the prompt is your way of communicating what you want the AI to achieve.

For large language models (LLMs) such as GPT-4, prompts can range widely. They might be as straightforward as a query like “What is 1 + 1?” or as complex as a problem statement embedded with various data types, including raw data from a CSV file.

Understanding Prompt Engineering

Now that we’ve explored what a prompt is, let’s delve into the field of prompt engineering.

I like this succinct definition from McKinsey & Company “Prompt engineering is the practice of designing inputs for generative AI tools that will produce optimal outputs.” As an analogy think of prompt engineering as a master chef crafting a gourmet recipe. Just as the chef carefully selects and combines ingredients to create a perfect dish, a prompt engineer carefully chooses words and structures them to elicit the desired output from an AI.

Continuing the chef analogy, prompt engineering blends domain knowledge with an understanding of different AI models. Essentially, the same way a chef must have an idea of what they want to cook before actually cooking and that the same ingredients yield different results under various methods, a prompt engineer must have a vision of their goals before prompting and recognise that different AI models respond uniquely to the same prompts.

The Business Case for Prompt Engineering

While the benefits of prompt engineering in enhancing AI interactions with Large Language Models (LLMs) such as ChatGPT and Claude are clear to those familiar with the field, they might not be as obvious to everyone. To clarify, here are four compelling reasons why businesses should consider incorporating prompt engineering:

1. Improved Accuracy and Relevance: Prompt engineering fine-tunes the interaction between users and AI, leading to more accurate and relevant responses.
2. Increased Efficiency: By optimising prompts, businesses can reduce the time and resources spent on revising outputs. Efficient prompts lead to better first-time responses, speeding up workflows and reducing the need for follow-up queries.
3. Innovative Use Cases and Applications: Well-crafted prompts can unlock new capabilities and applications for AI, from personalised marketing campaigns to advanced data analysis.
4. Competitive Advantage: Businesses that master prompt crafting can leverage AI more effectively than their competitors, leading to enhanced operational capabilities.

Principles of Prompt Engineering

With a solid understanding of what prompt engineering is and its benefits, we now turn our attention to the core principles that should guide every prompt creation process for Large Language Models (LLMs). These principles are essential for crafting effective and efficient prompts that maximise the AI’s capabilities.

With the key principles of prompt engineering in mind, consider the example below. Analyse the prompt, identify which principles it violates, and think about how you might modify it to improve both the prompt and the resulting output. This exercise is designed to test your ability to integrate these principles into your approach to prompting.

Exercise Example:

Task:

1. Identify Violations: Examine the prompt and list which of the six principles it breaches.
2. Propose Improvements: Suggest how to rephrase the prompt to make it more effective based on the principles outlined earlier.

Bonus Points: You identify issues beyond the principles I gave you.

Discussion: Reflect on how your proposed changes could alter the AI’s response, potentially making it more precise and relevant to the user’s needs.

Foundational Prompt Engineering Techniques

Now stepping into techniques, below is an overview of more common techniques which you can deploy in your prompts while also considering the principles I gave you earlier.

Few shot prompting:

Description: Few-shot prompting is a technique where demonstrations or examples are included in the prompt.

Example:

Chain of thought prompting:

Description: Chain of thought (CoT) is a technique that structures an input prompt in a way that mimics human reasoning.

Example:

Positive Prompting

A common and effective strategy in prompt engineering is to emphasize what the model should do rather than what it should avoid. This approach encourages specificity and directs attention toward the details that are crucial for eliciting good responses from the model.

Example:

Instead of saying, “Don’t give me too much technical jargon,” rephrase the prompt to say, “Use simple language and avoid technical jargon.” This tells the model exactly how to tailor the response to meet your needs.

Leading Words

Instructing a model to “think step by step” before generating a response can lead to more accurate and reliable results. This technique, known as using “leading words,” strategically guides the model toward a more structured problem-solving approach.

Ensuring clarity in your prompts

Just as quotation marks, bullet points, and line breaks make text easier for us to parse, these formatting elements also enhance the readability for LLMs.

Advanced Prompt Engineering Techniques

Below are some examples of more advanced techniques which you could consider using where the foundational techniques mentioned previously are not quite up to par or suitable.

Self-Consistency:

Description: Diverse reasoning paths are sampled in few-shot CoT, selecting the most consistent answer to enhance performance in tasks like arithmetic and common sense reasoning.

Example:

Prompt chaining:

Description: Prompt chaining uses sequential prompts to guide language models through complex, multi-step tasks.

Example:

Tree of thought:

Description: Tree of thought prompting” is a method that structures thinking like a tree. It begins with a central idea, the main trunk, and expands into related subtopics, the branches.

Example:

Tailoring Solutions for Specific Needs

Prompt engineering also encompasses more specialised methods that can be particularly beneficial for Businesses. In this section, we explore two such methods: Retrieval-Augmented Generation (RAG) and the use of agents.

Retrieval-Augmented Generation (RAG):

Retrieval-augmented generation combines the capabilities of a standard language model with the power of information retrieval systems. This technique enhances the model’s responses by allowing it to access and incorporate external data dynamically.

Potential application of RAG within Business operations

• Internal chatbot: Enhances accuracy and timeliness of responses in internal chatbots, helping employees access up-to-date company policies.

The Use of Agents:

Agents in prompt engineering refer to specialised prompts that instruct the AI to act as an intermediary or facilitator in achieving complex tasks. These agents can manage multi-step operations or handle tasks that require a series of interactions.

Potential applications of Agents within business operations:

• Post-campaign analysis: Automates the creation of detailed PowerPoint slides for marketing campaign analysis.

Call to action

Now that we’ve explored prompt engineering, it’s clear that there are significant opportunities for both individual employees and businesses as a whole to harness these capabilities. Here are some practical steps we can take to integrate and benefit from prompt engineering in businesses:

Actions for Individual employees:

1. Enhance Your Skill Set

• Engage in workshops and training sessions provided by your employer
• Consider completing a free course on prompt engineering:

https://www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers/

https://www.youtube.com/watch?v=kCc8FmEb1nY

https://www.youtube.com/watch?v=dOxUroR57xs

• Use daily tasks as opportunities to practice and refine your prompt crafting skills.
• Refer to the resource section included and have a look through some of the links for an even greater depth in Prompt engineering.
• Remain Informed on the latest AI initiatives within your company and at large.

2. Innovate and Share

• Test out different prompts in your work area and observe the outcomes. Document these experiments and share your insights with colleagues.
• If you are currently using AI tools in your work area and find them useful share them with others either directly in conversation or via posts on relevant channels.

Actions for Businesses:

1. Invest in Resources

• Acquire or subscribe to AI platforms and tools that allow non-experts to experiment with and deploy AI models.
• Build a comprehensive repository of best practices, successful prompts, and troubleshooting tips accessible to all employees.
• Offer training to understand AI technologies and prompt engineering basics. Online courses, workshops, webinars or even blogs like this one can be valuable.

2. Foster a Culture of Continuous Improvement

• Recognise and reward individuals and teams who contribute significantly to advancing our prompt engineering capabilities.

Resources for Further Reading

To deepen your understanding of prompt engineering, I’ve compiled a list of resources that have been instrumental in shaping the insights shared in this blog. These resources are categorised to help you navigate according to your interests, needs and level of current understanding:

1) Well-rounded source for overviews and detailed information: https://www.promptingguide.ai/readings

2) More focused on their own models but still a good general source: https://community.openai.com/c/prompting/8/l/top

2a) https://platform.openai.com/docs/guides/prompt-engineering/strategy-write-clear-instructions

3) Very advanced content: https://lilianweng.github.io/posts/2023-03-15-prompt-engineering/

4) Additional resource to consider: https://github.com/brexhq/prompt-engineering

5) Comprehensive list of 26 principles for prompt crafting: https://arxiv.org/pdf/2312.16171v1.pdf

6) Encompasses beginner to advanced content: https://promptengineering.org/

Unlocking the Power of AI with Effective Prompt Engineering was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Alex Mickhael

In today’s world, where data is crucial for making smart decisions and staying ahead, efficient data handling is key. At the core of managing data is a vital concept: data pipelines. Let’s explore what they are, why they matter, and how they function.

What are Data Pipelines?

At its core, a data pipeline is a series of interconnected steps that facilitate the flow of data from its source to its destination. Think of it as a conveyor belt that transports raw data through various stages of processing, transformation, and storage, ultimately delivering valuable insights that drive business decisions.

Why are Data Pipelines Important?

Data pipelines play a crucial role in modern data architecture for several reasons:

Efficiency: They automate data tasks like gathering, transforming, and loading, making workflows smoother and saving time and effort.

Scalability: With data growing rapidly, pipelines handle larger loads without losing speed or reliability.

Reliability: Pipelines include features for managing errors, validating data, and ensuring its quality, maintaining the trustworthiness of the processed data.

Real-time Insights: Thanks to real-time processing, pipelines deliver timely insights, empowering businesses to react swiftly to market changes.

How Do Data Pipelines Work?

Data pipelines manage the journey of data from its source to its destination. Here’s a closer look at how they operate:

Data Sources: These are where data comes from, like databases or applications. Pipelines pull data from these sources.

Data Ingestion: Once data is pulled, it’s brought into the pipeline. This can happen in batches or in real-time.

Data Processing: Inside the pipeline, data is cleaned, transformed, and structured for analysis. This ensures it’s ready to be used effectively.

Data Storage: Processed data needs a place to stay. It’s stored in databases or data lakes until it’s needed for analysis.

Data Orchestration: Data pipelines have many steps. Orchestration tools manage these steps, ensuring they happen in the right order and on time.

Conclusion

In conclusion, data pipelines are essential components of modern data architecture, enabling organizations to efficiently process and analyse large volumes of data from diverse sources. By understanding the importance of data pipelines and how they work, organisations can build robust data processing workflows that drive actionable insights and informed decision-making.

Data Pipelines: A Simple Guide for Beginners was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Kamran Bhatti

Introduction

Lets set the scene a bit. You get ready to start working on something when your phone gets pinged, theres been an alert for production. Your heart sinks a bit hoping its a miss fire but you check the alert and see its because JVM heap memory is too high. You inspect your metrics in grafana and see JVM heap memory has been steadily increasing over the past 4 hours and objects arent being collected correctly. You wonder if it was because of something you deployed into production just a couple days ago and start trying to diagnose the issue by grabbing some heap dumps to investigate which objects are still retained on the heap.

Hopefully this isnt a common occurrence but, no matter how much testing you perform, there will always be edge cases which cause issues in production. One that gave us a lot of trouble would be histogram timers. In this post, im going to walk through how we’ve used reflection to help us diagnose histogram timers not ending correctly and how using reflection just a tiny bit might be a good thing in high performance applications.

Background on reflection

What is it?

It allows us to inspect/modify classes, interfaces, fields and methods. We could also instantiate new objects, invoke methods and get/set field values regardless of their access modifiers.

When should it be used?

If you want to access methods, fields, classes or interfaces where they are set to final, private or protected, reflection can be very useful. In any other scenario, reflection should probably not be used as it is quite slow. This is because it must inspect the metadata of the bytecode to resolve against the string you provide instead of using precompiled addresses and constants.

Where is reflection commonly used?

One common scenario where reflection is used is in JUnit to retrieve and execute methods in a class by grabbing methods annotated with “@Test”

Simple reflection example

public class Car {
   private String make;
   private String model;
   private String engineType;
}

This is a simple example class which has private fields for make, model and engine type for a car. As the access modifiers for these fields is set to private, we can’t access them unless there is a public getter to retrieve the variable on the class.

@Test
void shouldGetFieldsFromCarObject() {
   final var car = new Car();
   Field[] fields = car.getClass().getDeclaredFields();
 
   List<String> actualFieldNames = getFieldNames(fields);
 
   assertTrue(Arrays.asList("make", "model", “engineType”)
      .containsAll(actualFieldNames));
}

This example test shows that we can get all declared fields on a class where we can retrieve the field names on the class to validate against even though the access to these fields is private and we shouldn’t be able to retrieve them.

How are we using reflection?

Why do we use reflection?

Sometimes, we would see increased memory utilization where for some reason, objects weren’t being collected by the garbage collector but were living till tenor which would cause memory to steadily increase until an alert would fire that we were meeting a memory limit on a specific node. After grabbing and inspecting a heap dump in eclipse memory analyser, we discovered that the leak was being caused by a histogram timing event not being ended correctly.

We use Prometheus in our production servers to collect metrics and aggregate our alerts in one location. The majority of our application code runs asynchronously where we use futures to handle logic that we want to execute without blocking the main threads of our application from spinning. Sometimes, some logic being executed on a future could throw an exception or the result of a future could throw an exception causing any histogram timers that haven’t had been ended yet to not be collected, causing a memory leak in our production servers.

Like many production systems, there may be many histograms collecting metrics so diagnosing which histogram is leaking memory would become quite the ordeal where the flow for each histogram would need to be followed and checked to ensure that the timing events for that histogram would end correctly.

We use reflection to retrieve every histogram we are collecting metrics with, and we retrieve the counters on each histogram. If the counter on a histogram has lived longer than a given amount of time, we log that the histogram parent for that counter is leaking memory and this process runs every couple of seconds.

This approach allows us to narrow our search area to a specific histogram leaking memory instead of inspecting how the flow of every histogram is used to ensure their timing events are ended correctly however, this approach wouldn’t be possible if we didn’t know the average time a timing event should live for. This also means that diagnosing this specific issue becomes easier as if this log is firing, we know a histogram is leaking memory. Therefore, if this log isn’t firing, we know we would have to grab a heap dump or jfr to further diagnose a production issue.

Example of the reflection we are using.

REFLECTED_HISTOGRAM_CHILDREN = SimpleCollector.class.getDeclaredField("children");
REFLECTED_HISTOGRAM_CHILDREN.setAccessible(true);
REFLECTED_START_TIME = Histogram.Timer.class.getDeclaredField("start");
REFLECTED_START_TIME.setAccessible(true);
REFLECTED_CHILD = Histogram.Timer.class.getDeclaredField("child");
REFLECTED_CHILD.setAccessible(true);
REFLECTED_HISTOGRAM_FULL_NAME = SimpleCollector.class.getDeclaredField("fullname");
REFLECTED_HISTOGRAM_FULL_NAME.setAccessible(true);
REFLECTED_HISTOGRAM_LABEL_NAMES = SimpleCollector.class.getDeclaredField("labelNames");
REFLECTED_HISTOGRAM_LABEL_NAMES.setAccessible(true);
REFLECTED_HISTOGRAM_TIMERS_MAP = AbstractMetricsReporter.class.getDeclaredField("histogramTimersMap");
REFLECTED_HISTOGRAM_TIMERS_MAP.setAccessible(true);

This code snippet retrieves the children, fullname and labelNames fields on the SimpleCollector class, the start and child field on a HistogramTimer class and the histogramTimersMap on our custom AbstractMetricsReporter class.

We use this data to determine if a specific histogram is leaking after a given time period where we log out the name of the histogram, labels on the histogram and the amount of time the histogram has been leaking for to help narrow down our investigation for a histogram timers map leaking.

Thoughts on reflection

Benefits

Reflection allows us to retrieve values on classes, modify elements and redirect method calls if we chose to which gives us more control over how we would want a specific application or library to function.

Drawbacks

The main drawback of reflection is that it can be inefficient in some use cases. As you are retrieving information of a class or object as a string to then access from an object, the process of string matching to the correct variable/method and then type casting or executing your custom business logic is time consuming and isn’t very performant.

When is it appropriate to use reflection?

In most scenarios, I would recommend against using reflection. If the code that is being modified is in the user space and lives with the business logic or application code that you have specified, it makes more sense to create getters or setters to help with modifying the state of that object. Using reflection breaks object oriented paradigms and should be avoided if the functionality you are trying to achieve can be done without the use of reflection.

It makes more sense to use reflection for external libraries such as Prometheus where the functionality you are trying to achieve isn’t possible using the API of the underlying library. We have opted to execute this logic on a separate thread which Is executed periodically to ensure the rest of applications performance isn’t adversely affected by performing this reflection process continuously.

By Yasmin Dawoodjee

Just over 6 months ago, I started a new career in Technology after studying chemistry in undergrad, the main question I always get asked is: “why?”. After being exposed to computational chemistry, (which is a branch of chemistry that uses computer simulations to assist in solving chemical problems), I realised that technology is an area I wanted to explore and could be the career for me. Following a quick gap year filled with short courses on the basics of code with Code First Girls and similar initiatives, I was offered a place on the Global Technology & Digital Early Careers Programme! While most companies required a computer science degree or equivalent, my previous experiences have been treated as an asset and I’ve been able to use many transferrable skills which have helped me on this journey as an IT business analyst. Here’s what I’ve learnt in the last 6 months!

Embracing Challenges

One of the challenges I encountered quite early on was not having the same level of business knowledge as everyone else around me. However, I quickly learnt that it is not about what you know — it is about what you can learn. Success in the workplace isn’t solely dependent on your existing knowledge; it hinges on your capacity to absorb new information. As a newcomer to the job market, you’re unlikely to possess the exact experience required for most positions, no matter how many internships you’ve completed. Transitioning to full-time employment brings its own set of challenges. However, this is perfectly normal. No one anticipates you to have all the solutions from day one, and I’ve been lucky enough to have the support and opportunity for learning at every step of the way. Increasingly, especially for entry-level positions, companies are prioritizing traits and behaviours over specific skills.

You don’t need to be a “techie” to work in tech

Technology encompasses a wide range of roles, extending beyond the conventional image of a solitary engineer coding at a desk. While many tech jobs do require technical proficiency, they also demand essential soft skills such as communication, collaboration, critical thinking, and adaptability.

The roles within the tech industry can be broadly categorised as follows:

• Product owners, delivery managers and analysts: responsible for delivering IT systems and aligning them with the company’s objectives.
• Data scientists and researchers: utilise technical expertise to tackle complex problems, driving innovation and progress.
• Programmers and developers: Engage in building applications or solutions, often collaborating closely with business stakeholders for feedback.
• IT support: provide assistance and resolve issues for both internal and external customers, witnessing the direct impact of their work on a daily basis.
• Customer-facing technical roles: serve as trusted advisors to customers, offering insights into technology solutions and aiding in solving business challenges.

As a business analyst in a tech department, I’ve found that one of the most valuable aspects of my role is the ability to bridge the gap between technical teams and non-technical stakeholders. Rather than being lost in a sea of tech jargon, BAs like myself focus on fostering communication and understanding. For instance, I’ve developed skills in translating complex technical concepts into plain language, which facilitates collaboration between developers, project managers, and business leaders. This ability to communicate effectively has been essential in ensuring that everyone involved in a project is on the same page and working towards shared goals.

Professional development can happen through observation.

I quickly learned that despite my usual way of learning is reading textbooks, or attending training sessions, learning doesn’t always happen through formal training or structured programs. Much of it occurs through observation, informal conversations, and absorption from experienced colleagues. Unsurprisingly, I learn by example and mirroring others — by asking to be in a variety of meetings and shadowing colleagues, I have the opportunity to witness effective communication, decision-making processes, and professional conduct first hand.

While remote working has its many benefits, being physically present in the office helps me absorb the company culture and understand the unwritten rules that contribute to success within the organization. This observational style learning is extremely valuable in shaping my own professional development.

Diversity in tech matters

I’ve been lucky enough to join a company where there are many initiatives to encourage diversity in tech. From regular women in tech meetups to a whole week filled events and training workshops during international women’s week, there is a lot to get involved in! A diverse workforce brings unique perspectives and experiences that can lead to more innovative solutions and a better understanding of customers. While many tech companies are now embracing diversity, there is still a long way to go. Here are a few statistics from this year’s tech talent charter.

• 21% of senior tech role holders are women.
• 25% of UK tech employees are ethnic minorities; 5% are Black.
• 22% of software engineers are ethnic minorities.
• Only 9% of tech employees are reported to be from lower socioeconomic backgrounds. This compares to 39% of the UK population.

What’s next?

Reflecting over the past six months has made me eager for what lies ahead! It’s been a period of intense learning and adaptation, and I’m ready to carry that momentum forward. In the coming months, I plan to continue exploring different avenues within the tech industry, further developing my skills, and staying open to new opportunities. Networking, seeking guidance from mentors, and remaining resilient will be essential. With each new challenge, I know I’ll gain valuable experience that will help me advance in my career.

From Chemistry to Business Analysis: My journey into Tech was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Joe Maskery

What is an API?

As someone new to software development, one of the most important concepts I have been introduced to is APIs. API stands for Application Programming Interface; they are mechanisms that enable two software applications to talk to each other using a set of protocols and definitions.

The most common types of API used at Global are REST and GraphQL. Whilst REST is the most popular type of API used today, GraphQL is relatively new and offers some exciting features which this blog post will summarise.

GraphQL

GraphQL is a data query and manipulation language and query runtime engine for APIs. The main selling point of GraphQL is that it allows clients to request only the exact data they need from the API, compared to REST where API responses are fixed and defined by the server.

How it works

GraphQL APIs only have a single endpoint where clients send all requests; these requests are then validated, interpreted, and executed by GraphQL. This is very different to REST APIs which have multiple endpoints to each fulfil a different request.

GraphQL has two main operation types: queries and mutations. Queries are requests that retrieve data from the server, like the HTTP GET method, whereas mutations are any request which modifies a resource, like the HTTP POST, PUT, and DELETE methods.

To setup a GraphQL API you need to define a schema file. This schema file should contain the definitions for all Object types that will be transferred across the API as part of a client request or a server response. Additionally, the schema file should contain definitions for any queries or mutations that the API will perform including their names, required parameters, and response objects.

Any query or mutation defined in the schema file will also require a resolver. Resolvers are methods or functions that are assigned to each operation to perform the logic required to resolve the request, e.g. retrieve the requested data from a database. The way resolvers are implemented will vary depending on the language or framework that the application uses.

In summary, the GraphQL schema file contains the definitions for all object types that can be transferred across the API, and the templates for all operations that can be performed by the API. A key feature of GraphQL is that it allows multiple operations to be sent and resolved as part of the same request. As long as the request is valid against the schema file all operations will be resolved in the single request.

Pros and Cons

Advantages

· Eliminates over-fetching: GraphQL allows clients to request only the exact data they need and nothing more. This reduces network traffic and improves the performance of client applications.

· Eliminates under-fetching: clients can retrieve all required data from a single request to the API, instead of making multiple requests to multiple different endpoints.

· Flexibility: clients have full control over the shape and structure of the data they receive and can retrieve nested or related data in a single request.

· Strongly typed schema: the GraphQL schema provides a clear contract between the client and the server, and clients can use introspection to see all available types and fields.

· Versionless APIs: because clients request only the specific fields they need, it is easier to add new types and fields without causing any breaking changes.

Disadvantages:

· Complexity: implementing a GraphQL API can be more complex than traditional APIs such as REST. It has a learning curve and developers need to pick up the key concepts such as the schemas, queries and mutations, and resolvers.

· Performance overhead: GraphQL servers need to parse and execute complex queries which can require more intensive processing when compared to REST APIs, especially for resource-intensive applications.

· Caching: caching is a challenge as GraphQL responses are generally unique to each query, especially compared to REST APIs where responses are more standardized.

Example

To illustrate the above points we can look at an example. Taking an example of a Spring application which handles Order-Lines and Order-Line-Items, the schema may look something like this:

type OrderLine {
    orderId: ID!
    company: String!
    dateCreated: String!
    numItems: Int!
    totalPrice: Float!
    orderLineItems: [OrderLineItem!]
}

type OrderLineItem {
    itemId: ID!
    orderLineId: ID!
    orderLine: OrderLine
    product: String!
    startDate: String!
    endDate: String!
    duration: Int!
    price: Float!
}

input AddOrderLineRequest {
    company: String!
}

input AddOrderLineItemRequest {
    orderLineId: ID!
    product: String!
    startDate: String!
    endDate: String!
    price: Float!
}

type Query {
    getAllOrderLines: [OrderLine!]
    getOrderLineById(orderId: ID!): OrderLine

    getAllOrderLineItems: [OrderLineItem!]
    getOrderLineItemById(itemId: ID!): OrderLineItem
}

type Mutation {
    addOrderLine(addOrderLineRequest: AddOrderLineRequest!): String
    addOrderLineItem(addOrderLineItemRequest: AddOrderLineItemRequest!): String
}

From the schema it is easy for us to see all available objects and operation types in the API and exactly how to call them.

Now we can see how easy it is to construct a request containing multiple queries and get the data back in a specific shape with only the required fields:

query GetAllOrderLines {
    getAllOrderLines {
        orderId
        company
        dateCreated
        numItems
        totalPrice
        orderLineItems {
            product
        }
    }
    getOrderLineItemById(itemId: "3") {
        itemId
        product
        startDate
        endDate
        duration
        price
        orderLine {
            company
        }
    }
}

From the response we can see how easy it is to work with related data, as we are able to easily see the relationships between the Order-Lines and the Order-Line-Items.

{
    "data": {
        "getAllOrderLines": [
            {
                "orderId": "1",
                "company": "Company 1",
                "dateCreated": "2024-04-03 14:05:24.927713",
                "numItems": 3,
                "totalPrice": 2178.99,
                "orderLineItems": [
                    {
                        "product": "Bus asset"
                    },
                    {
                        "product": "LU asset"
                    },
                    {
                        "product": "Bus asset"
                    }
                ]
            }
        ],
        "getOrderLineItemById": {
            "itemId": "3",
            "product": "Bus asset",
            "startDate": "2023-11-13",
            "endDate": "2024-04-25",
            "duration": 165,
            "price": 423.99,
            "orderLine": {
                "company": "Company 1"
            }
        }
    }
}

Both REST and GraphQL APIs have their pros and cons, and when deciding on which type of API to use it’s important to consider the requirements of your application. It’s also important to consider that GraphQL can be applied to an application on top of a REST API. In my team for example we have found it best to use a combination of GraphQL, for communication with the front-end, and REST APIs, for communication between back-end services, as each one has its benefits for slightly cases.

GraphQL APIs was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Ella Myton

In the past, trading in the OOH world has been a bit like trying to navigate without a map. Each agency or specialist had their own way of working, which meant every integration required a custom approach. This not only slowed things down but also ate up valuable resources. With Open Direct, the aim is to change all that. By providing a standardised way for agencies and media owners to connect and trade.

So, what is Open Direct? OpenDirect is an API specification that revolutionises the way Out-of-Home (OOH) inventory is bought and sold. This was initialised through a collaborative effort involving industry giants such as AOL, Microsoft, Yahoo, and Yieldex. It was later bought to the IAB (Interactive Advertising Bureau) who released the first version in January 2015. What began as a solution crafted by a select few has blossomed into a universally embraced standard. With OpenDirect, buyers and media owners alike benefit from increased workflow efficiencies, greater control over inventory management, and a reliable means of automating the trade of OOH inventory. It’s not just a technological innovation; it’s a testament to the power of collaboration and standardisation in driving industry-wide progress. It gives buyers the ability to use their own platform to connect with media agencies such as Global to check the availability of inventory and book slots for both classic and digital frames.

How is OpenDirect going to help Global?

• Increased Efficiency: OpenDirect will facilitate faster deal closure and minimise administrative overhead by reducing manual intervention and streamlining workflows. This, in turn, will lead to substantial long-term cost savings.
• Transparency is at the core of OpenDirect, as it promotes clarity in the advertising ecosystem by offering transparent terms, pricing, and delivery specifications from the outset. This commitment to transparency fosters trust between us and our customers, minimising the likelihood of disputes and paving a way to develop long lasting relationships. It also encourages greater collaboration, more frequent transactions, and a potential increase in spending from our buyers, ultimately leading to revenue growth.
• Forecasting and Reporting: OpenDirect offers enhanced visibility into future inventory availability and demand for both Global and our Buyer. This access to real-time data and insights empowers us to optimise future inventory management strategies, thereby maximising revenue potential. Improved forecasting and planning capabilities result in a more efficient allocation of advertising budgets and increased revenue generation.

So, how’s it going now?

The advancements in the development process have been incredible. We started under a year ago and the team have already released to pre-production. We are currently testing with the five of our main specialists that trade with us. The testing phase is where all the excitement is. It’s the first time we’ll see all the individual Jira tickets come together. Our specialists have successfully connected to Globals OpenDirect API, and we are so excited for the release to production. Watch this space!

Navigating the New Era of Out-of-Home Advertising with Global’s Open Direct API was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

When a Python program is running, a thread executes instructions in the code. By default, one thread executes for a Python process. This thread is usually called the main thread.

The following code defines three functions. Each function sends a GET request to a specified webpage, waits for the server’s response to the HTTP request, then prints the status code of the response. The thread name and associated thread ID are also logged in the terminal. Here, the functions are executed sequentially — one after the other.

import time 
from loguru import logger 
import threading 
import requests 

# Define functions which try to request a webpage and print the status code 
def task1(): 
    logger.info("Task 1 started") 
    logger.info(f"Task 1 thread: {threading.current_thread().__class__.__name__}; thread ID: {threading.current_thread().ident}") 
    response = requests.get("https://www.globalplayer.com") 
    logger.info(f"Task 1 status code: {response.status_code}") 
    logger.info("Task 1 completed") 

def task2(): 
    logger.info("Task 2 started") 
    logger.info(f"Task 2 thread: {threading.current_thread().__class__.__name__}; thread ID: {threading.current_thread().ident}") 
    response = requests.get("https://www.heart.co.uk") 
    logger.info(f"Task 2 status code: {response.status_code}") 
    logger.info("Task 2 completed") 

def task3(): 
    logger.info("Task 3 started") 
    logger.info(f"Task 3 thread: {threading.current_thread().__class__.__name__}; thread ID: {threading.current_thread().ident}") 
    response = requests.get("https://www.lbc.co.uk") 
    logger.info(f"Task 3 status code: {response.status_code}") 
    logger.info("Task 3 completed") 

# Execute tasks sequentially 
if __name__ == "__main__": 
    print("Sequential task execution:") 
    start_time = time.time() 

    task1() 
    task2() 
    task3() 

    end_time = time.time() 
    total_time = end_time - start_time 
    logger.info(f"Total time taken: {total_time} seconds") 

The functions execute in sequence, so task1() needs to be completed before task2() can start. Task1() makes a GET request to https://www.globalplayer.com, waits for the response and prints the status code of the response. Task3() starts when task2() is complete. It takes around 0.4s in total for task1(), task2() and task3() to run:

For each task, the same thread is used — the main thread.

If the tasks could start independently, without waiting for other tasks to finish, the program could execute more quickly. To do this, we could introduce more threads, which will allow separate parts of the program to run out of sequence.

One method of running multiple threads simultaneously is by using ThreadPoolExecutor, from the concurrent.futures module in the Python Standard Library. This uses a pool of threads to execute the functions asynchronously.

import time
from loguru import logger
from concurrent.futures import ThreadPoolExecutor
import requests
import threading

# Define functions which try to request a webpage and print the status code
def task1():
    logger.info("Task 1 started")
    logger.info(f"Task 1 thread: {threading.current_thread().__class__.__name__}; thread ID: {threading.current_thread().ident}")
    response = requests.get("https://www.globalplayer.com")
    logger.info(f"Task 1 status code: {response.status_code}")
    logger.info("Task 1 completed")

def task2():
    logger.info("Task 2 started")
    logger.info(f"Task 2 thread: {threading.current_thread().__class__.__name__}; thread ID: {threading.current_thread().ident}")
    response = requests.get("https://www.heart.co.uk")
    logger.info(f"Task 2 status code: {response.status_code}")
    logger.info("Task 2 completed")

def task3():
    logger.info("Task 3 started")
    logger.info(f"Task 3 thread: {threading.current_thread().__class__.__name__}; thread ID: {threading.current_thread().ident}")
    response = requests.get("https://www.lbc.co.uk")
    logger.info(f"Task 3 status code: {response.status_code}")
    logger.info("Task 3 completed")

# Execute tasks asynchronously
if __name__ == "__main__":
   print("Asynchronous task execution:")
    start_time = time.time()

    with ThreadPoolExecutor(max_workers=3) as executor:
        executor.submit(task1)
        executor.submit(task2)
        executor.submit(task3)

    end_time = time.time()
    total_time = end_time - start_time
    logger.info(f"Total time taken: {total_time} seconds")

This program can now run faster as, while task1() is waiting to finish, task2() can start, and so on. In the terminal output shown below, one particular execution ran in around 0.18s. New threads have been created here to have multiple, separate flows of execution.

Python threading can be used to decrease the time taken for a program to execute, by allowing tasks to run concurrently. The global interpreter lock restricts the potential of multithreading in Python, as it does not allow multiple threads to run two different processes at exactly the same time. Instead, the threads take turns running a process to speed up the overall program.

However, the global interpreter lock is released for I/O operations (such as web requests, like in the example above). So, multithreading can be used to run I/O operations concurrently.

An issue that can arise with multithreading is a race condition. Race conditions can occur when multiple threads attempt to make changes to a Python object at the same time. This can cause data to be changed incorrectly, introducing errors and potentially security vulnerabilities into the code. This can be avoided by synchronising access to shared data, using a lock, for example.

In summary, multithreading is one method of reducing the time taken for a Python process to execute. ThreadPoolExecutor can be used to introduce multiple threads, which can allow different parts of the program to run asynchronously.

Basics of Python Multithreading was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Aislinn Wright

Finding Fires: Smoke Testing in Software Testing

Smoke testing, a form of software testing, is performed during the early stages of development as an initial test to establish that core functionality is performing as intended before moving to more detailed testing. Smoke testing is a cost-effective and time-efficient method to check the initial quality and stability of a new piece of software, preventing wasting resources on detailed testing that may need to be repeated should core functionality require changes.

Also known as verification testing or confidence testing, the term smoke testing originates from the electronics industry where the initial tests of electrical components included looking for visible smoke which could indicate a critical failure of a component. Smoke testing is now characterised by its broad but shallow testing modal, aiming only to test that core functionality has been achieved. Through testing core functionality early in the development process, critical bugs can be resolved swiftly with minimal impact on the wider project, preventing significant delays in the later stages of development.

Typically, smoke testing is carried out either on a daily or per build basis, as per the project’s needs. Daily testing is particularly beneficial for projects with frequent builds and continuous integration, ensuring that each build meets quality requirements and core functionality is not compromised by the introduction of new bugs. In the instance that a bug is introduced, by testing daily it is easier to pinpoint when bugs were introduced and roll back deployments if necessary.

Depending on the needs of a project, smoke testing can be adapted to target specific areas of the project. Two popular forms of smoke testing are acceptance smoke testing and UI smoke testing. Acceptance smoke testing aims to establish if a new piece of software meets the acceptance criteria previously agreed upon by clients or stakeholders of the project. Acceptance smoke testing is done only to establish that the MVP has been met with the intention of later performing more detailed testing. Alternatively, UI smoke testing focuses solely on the user interface components, ensuring that the customer facing product is functioning as intended to create a positive experience for the user.

Smoke testing can play a significant role in the software testing process, providing an early check of the quality of a new piece of software. Through broad but shallow early testing, smoke testing prevents wasting resources on detailed testing before core functionality has been established. Smoke testing has become a method to detect issues early, promoting the overall quality of the product.

Finding Fires: Smoke Testing in Software Testing was originally published in Global Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.