Thursday 2 February 2023
We use software everyday of our lives whether we realise it or not. Over the last half a century it has crept into everything we interact with on a daily basis, whether it be putting on the washing machine to setting an alarm clock in the morning. Software is used everywhere in modern life but the type of software that we are more familiar with nowadays we tend to call “Apps”, a short version of the name Applications.
Applications are what we tend to call software that sits on top of an existing software environment like an operating system, which we find in most computers and phones nowadays. These applications have become abundant and anyone can download an “App” to their phone that will help them do something they want to achieve. The developers of these applications have changed too, with many more people creating them who weren’t trained to be software developers. The actual development tools themselves have been designed for non-technical people but at what cost does this come?
Back in the early 1980’s, when computers first started to appear in people’s homes, many youngsters became interested in programming (known as “bedroom programmers”) who attempted to write software that would interact with the machine’s hardware, even if it was simply making the screen flash or make the words “Hello world” be displayed all over the screen. This was the first real moment where software development became accessible to all. Prior to this, most software was written on Mainframes and much of the business software was developed in languages like COBOL (Common Business Orientated Language) which were only accessible to large businesses which could afford the hardware and staff to develop the software.
It was more difficult to write software on these early home computers in some ways, as all the software written was machine-dependant and could not be transferred to different makes of computer without a lot of modification, or even being completely rewritten. This made early software very unsustainable for many small software companies to develop, with many having to specialise in writing software specifically to certain makes of computer.
With the advent of modern PC’s (Personal Computers) developed by various manufacturers such as IBM using a common Operating System known as DOS (Disk Operating System), it was now possible to develop software that would work on all of these manufacturer’s computers provided the architecture of the hardware met certain requirements. It was certainly a huge step forward in standardisation, reducing the time taken to develop software and it also allowed software to be sold to people regardless of the make of PC they chose to buy. The DOS operating system unified the hardware of the time and when Microsoft released their first version of Windows which was an application that sat on top of the DOS operating system, it showed what Microsoft intended to do in the future.
The DOS operating system was developed at a time when computers typically had up to 640K bytes of memory and, although many computers in the early 1990’s started to be produced with more memory than this, any memory past the 640KB barrier was for the operating system to use and not for applications that sat on top of DOS. This was fine for a long time but as developers created larger and larger programs this 640K limit became a real problem. Many software developers frequently hit this limit and had to come up with ingenious ways to fit the software developed into a finite space. This usually happened by breaking software into smaller programs that could swap places with each other when a user accessed a different part of the application. Although it made the software very efficient from the user’s perspective it increased the development costs. Being commercial software, the developer also had to take into consideration that the end user may not have as much free memory available as themselves, so it was important keep this in mind when developing software otherwise it would cause support issues further on in the software’s lifecycle. There was a trade-off in this style of development in that if this was a piece of software being sold to many then it was better for the cost of making the software more efficient to be absorbed by the developer themselves, rather than the end user who may potentially need to upgrade their hardware to run it. Comparing this to the other side of the trade-off where the software was only being used by one client, then it was more economical for the customer to buy new hardware to run software that was written less efficiently.
This concept of the 640KB memory limit would cause developers to have to think far more economically when creating software, especially when developing code that may have to work alongside existing pieces of software developed by other 3rd parties. Although the software took longer to write and was more expensive, the knock-on effect of this hardware-conscious programming style was that the users of the software did not need to upgrade their hardware as often, as the software was written to work far more efficiently in this tiny amount of memory.
With advent of Windows 95 being released, things completely changed from a developer’s point of view. This version of Windows removed the 640K bytes barrier for many due to the ability programs now had to utilise any additional memory the computer had. This wasn’t an immediate success as most of the software still being used at that time, especially in commercial environments, was still DOS-based which now sat in a “MS-DOS Shell” on top of Windows.
Many software developers were now redeveloping their software from scratch to utilise the new Windows environment which no longer had the limitations. This new wave of software allowed developers to create whatever they wanted without having to take into consideration any of the limitations of memory or performance as new hardware technology was also being developed so fast. The development tools also became more accessible to many people, and these tools focused on “High Level Languages” such as C-sharp which were easier to learn than “Lower-Level Languages” such as assembler and machine code. This whole shift made it cheaper to develop software as the required skill level changed and developers tended to be taught fewer languages with less restrictions on how they could develop software. However, this new freedom encouraged software to be written with less care and less efficiently.
With the rising popularity of the internet in the late 1990’s, software development shifted once again with new languages being created but with a more efficient mindset being considered again, like the old days. There wasn’t a memory limit anymore but there was a limit on bandwidth, how much data could be passed over the internet at once, especially in the early days when Dial-up modems were used on existing phone lines. Software developers had to make their software as efficient and as fast as possible if it was situated on a web server for users to access in the form of websites or as compressed as possible especially when transferring data from point to point. An example of this could be an EDI (Electronic Data Interchange) transferring order requirements between the customer and the supplier. This once again increased development costs in situations where optimum performance was required. Within Solweb we develop software that moves millions of records daily between multiple locations, the requirement for speed, stability and security is a priority. As broadband providers have improved the speed dramatically over the years both in landlines and mobile phone services, speed is still a limiting factor to many businesses.
The dawning of the internet also brought about another shift in software development, that of Outsourcing. Different software companies could collaborate on projects which could be brought together for the customer at a cheaper cost. However, although the rates in offshore outsourcing can be less, there is often a lot more time needed to produce the software. This means delivery times are quite often pushed out dramatically and if any software bugs are found it can cause major issues for customers as fixes are slower to be rectified. Many offshore software companies also develop using the “Agile” concept which gives the customer flexibility to change development priorities between releases but this can have huge (and expensive) implications if there are multiple software companies in the supply network waiting for certain functionality to be released, especially when some of the software suppliers use the “Lean” concept rather than “Agile”.
Although many people are releasing their own Apps nowadays, software development in commercial environments has stayed much the same for the last decade at least, or did up until the lockdowns of 2020 which changed things for many businesses.
With all staff working from home from March 2020 many experienced a huge increase in utility bills where all computers were left on 24/7, increasing power consumption to approx. 300% of the same period 12 months earlier. Although all the video conferencing and phone infrastructures were in place, communication and creativity was stifled and output in productivity dropped noticeably. Although software development is a very methodical process, a lot of creativity is also required. The lockdown certainly impeded this and this in turn created stress for employees, affecting their wellbeing.
From a commercial perspective, the lockdown also generated a considerable influx of enquiries where business owners were struggling to work in a limited capacity with many of their staff off site or on furlough. People were looking to automate processes in their business to help a skeleton crew of staff carry out all the functions that it normally took a larger team to do. Although we normally develop software to automate processes for people, business owners were now seeing how critical it was to their business to have things in place to increase their efficiency.
So, with power consumption used in the information and communications technology sector expected to account for 14% of the world’s carbon footprint by 2040, almost 10 times what it was in 2007, how can we incorporate some of the greener and more sustainable development techniques of the past, especially in these fast changing and uncertain times?
Firstly, we can look at the design of the software from the users’ point of view. It’s not just about the development of the software that we can provide as a software developer but we can also influence how the individual uses it in their business. With ERP software providers such as SAP and Kerridge to name but a few adapting their software products to encourage their users to use concepts such as the “circular economy”, it is very encouraging that things are being done to make things more sustainable in the work place of the company using it. Software developers have a huge opportunity to influence the end users, even if it is down to something as simple as popping up a box if the software hasn’t been used for some time so it can be closed to save power, especially on devices like phones and tablets where power economy is probably the most important factor of its functionality.
With regards to software development, we have seen that twice in the past there was a reason to develop software as efficiently as possible to save on memory and bandwidth. We are now moving into a 3rd cycle where we need to be saving power. This can be accomplished, like before, by writing software in a way that considers this concept. Although not currently a restriction in the development of the software, it is an ethical modality that should be adhered to.
Solweb already utilise the circular economy’s “produce-use-reuse”concept in-house by reusing and recycling existing software code where possible from previous projects which can reduce development time and increase efficiency. We have also developed a digital platform of development tools which we utilise on every project but can we create any more tools to save time, or can we write them in a better way to take less memory and CPU usage, and therefore electric consumption, embracing the concept of Natural Capitalism?
Just like Biomimicry in nature, we have to keep adapting and evolving these tools which can connect to other 3rd party vendors and as they change their software. Every time we do this, we should aim to make these changes as efficient as possible so that every client of ours that utilises our digital platform can benefit from these changes. We can also roll these changes out to our existing client base potentially saving power on machines running our applications. Software fortunately lends itself to being a closed loop system as opposed to the “take-make-waste” of many other industries as we can change and deliver updates very quickly.
We can also look at developing internal KPI’s to measure the power consumption of the software we develop using tools such asw Power Gadget which was developed by Intel to monitor power-consumption which can be utilised when deploying software. We should also take into consideration how the software will be deployed. Will it be on the customers local machines, on our own web servers or on our Microsoft Azure servers where we have many companies host Software-as-a-Service products. Maybe we need to take this into consideration and calculate which deployment will have the smallest ecological impact and offer this suggestion to the customer when providing a quotation to them for their individual project.
Moving forward, even though we at Solweb are pretty much a paperless office and a business that has very few suppliers, there is still room to improve our carbon footprint. As a business ourselves we are also fortunate enough to be able to have an impact on the carbon footprint of our customers through the software we provide them with.
The biggest thing we can do moving forward is to collect and measure the data on the things we are looking to improve through KPI’s and to keep continually reviewing our operations to make sure we keep trying to be the best we can be.
