How much does this software weigh?

Sounds like an absurd question. It is software, isn't it, it is not physical, how can it be weighed?

A Space Age Question

NASA project managers asked such questions from their software contractors developing code to run on satellites and space vehicles. The rationale behind this question was that NASA would load that software on ROMs (Read Only Memories) on processors on board these platforms. Furthermore, software would also need read/write memory (RAM - Random Access Memory) at runtime as scratchpad to store results of computation. Larger the size of the runtime code and larger its memory utilisation, more memory chips needed to be installed on those processors which increased the weight, size and the power consumption of these processors in confines where all these physical attributes were at a premium.

So, while software is not physical, it needs physical resources to run and they have physical attributes. Paradoxically, while software itself does not weigh, it does add to the weight and the size of its hardware.

On A Silicon Binge

Embedded systems developers writing software to run inside most machinery like automobiles or aircraft face similar constraints. However, for programmers working on desktop, web, enterprise and even mobile applications, such concerns have largely been irrelevant because the cost of physical hardware has been dropping like a rock and Moore's Law (processor capacity and performance doubling every two years) has guaranteed performance for poorly written and bloated code.

But this has had an impact. In many cases, performance of newer versions of applications has dropped without any meaningful extension in their functional or non-functional attributes. This, in turn, has required hardware upgrades leading to higher physical occupancy in data centres, higher power consumption, significantly higher cooling requirements leading to even further power consumption. Consequently, this results in higher costs and shrinking margins which has put a spotlight on overall IT spend of firms as a major cost of running a business.

Mitigation

Increasingly businesses are realising the wastage in IT and are adopting measures to economise their IT spend. A common strategy is virtualisation where one server is made to appear as multiple virtual servers each taking a proportion of resources of the physical server. This allows hosting multiple applications on a single physical server where each application requires fewer resources than those physically available. This has the potential of lowering the overall infrastructure footprint in a data centre resulting in significant cost savings.

More recently, businesses are considering hosting their applications on cloud-based infrastructure. There again has potential for economising on IT as, in the cloud, businesses are charged for what they consume. Infrastructure management becomes the responsibility of cloud service providers with the subscribers reducing their administration overheads to only the interoperability with the cloud. Internally, cloud service providers may use virtualisation to increase their margins unless a subscriber specifically requests separate hosts for their applications for a higher subscription.

Code: The Common Denominator

But in the end, it is software being hosted on virtual servers or the cloud. Without lightening software or removing its bloat, cost savings are severely limited. It may even be more expensive to host severely bloated applications on the cloud with usage based tariffs.

Engineering lean software requires consideration in all phases of its development life cycle. During development, unnecessary features may not be included even if little or no development effort is required in including them. While there may be no development costs associated with a feature, there will be runtime or deployment overheads leading to costs.

Unnecessary caching that has little or no impact on the application meeting or exceeding its SLA (Service Level Agreement) should be avoided. In many cases caching is used to mask inefficiencies in the application or the infrastructure. Efforts to remove those inefficiencies deliver far higher dividends especially when such infrastructure is shared amongst many applications.

Use of third party dependencies should be questioned, especially in cloud-based applications where the cloud provider does not support these dependencies in their technology stack. These can have a substantial impact on an application's footprint and may require the cloud providers to make special provisions to accommodate such applications.

Quality assurance should not just test applications against a functional specification but also against established benchmarks on resource consumption and performance. Release of applications not meeting those benchmarks within specified margins may be reconsidered.

Applications should be constantly monitored in production for their performance and resource consumption. Monitoring should also reveal features that are rarely used or their usage drops below a certain threshold so that their existence within the application may be negotiated with users.

Finally, agility closes the loop as it enables optimising deliverables at the end of each iteration. Application resource requirements could be determined more accurately allowing finer grained virtualisation and better infrastructure utilisation.

A Personal Perspective

I graduated as an avionics systems engineer and spent the first few years of my career maintaining airborne electronics systems. Volume and weight constraints of equipment on fighter jets are no less than that on space vehicles. I experienced some interesting innovations focused primarily on economising on space, weight and power consumption of modifications on military aircraft.

During my transition to enterprise software development, I experienced frugality and simplicity in coding but not at the cost of functionality. I had opportunities to test applications on the leanest servers in the inventory. Optimising applications on those platforms allowed them to execute faster on more resourceful machines.