2

I have heard that over time, software can begin to show signs of wear and tear.

What does wear and tear of software mean?

Software itself not being a physical entity, so how can there be wear and tear?

Improve this question
5
  • 1
    I would ask the people who use such terms to describe them more clearly. Maybe they simply mean that it doesn't change any? – user Oct 26 '12 at 11:32
  • 1
    The saying goes something like.. "Eventually everything turns into en.wikipedia.org/wiki/Big_ball_of_mud" – Zavior Oct 26 '12 at 11:41
  • @Zavior - as software grows, even with a good design, it appears to become a big ball of mud, but that's mostly due to perspective. Even a sports car looks like a big ball of mud from an ant's point of view. – Scott Whitlock Oct 26 '12 at 11:46
  • @Nilesh - Well written software does not experience this effect. Although all software can experience of having to many features which leads to performance testing issues. One only has to look at Windows to see this effect, by leaving old features in for compatability reasons, its harder to solve the problems of the past. This means the bugs that existed in the past still exist, plus all the other bugs you create, by adding additional features. – Ramhound Oct 26 '12 at 12:22
  • 1
    "Software rot" or "code rot" are probably the most common terms used, so I believe we should stick to those and use them as "de facto standard" for this phenomenon. Introducing new terms like "wear and tear" doesn't really make anyone happier. It was probably someone who wanted to sound important at some point, that invented yet another new synonymous term. – user29079 Oct 26 '12 at 13:39
14

What is probably being referred to is software entropy or software rot. These are terms borrowed from or analogous to things from the physical world, but applied to software.

The idea is borrowed from thermodynamics. When applied to software, it means that as you introduce changes into a system, the system only gains disorder. There are techniques that can be used to limit the amount of disorder, such as refactoring, but over the course of its life, there will be a net increase in the disorder of the system. The amount of disorder is often tied to the ability to continue to maintain the system.

Software rot is similar. As you change any aspect of the system, from the environment that it runs in to the underlying requirements that drove the design and implementation, the state of the system changes in a way that makes it "worse". It could range from cosmetic differences (an underlying UI library is updated and behavior of the system changes) to functional (changes in CPU architecture influence the run-time characteristics of the system, leading to timing or synchronization bugs). Software rot doesn't necessarily require changes to the software system, but only in the environment in which the software is deployed.

Improve this answer
3
  • Interesting, I had understood these terms to mean something different; you're version makes sense but what I had seen was more about time-without-maintenance where the developers forget about the things they had needed to correct or redesign and so more things go uncorrected or poorly designed when software is left idle rather than actively maintained in good order. Software rot in my mind happens where refactoring is not allowed in risk averse software companies. So what was done poorly once just rots all the code around it because it's not allowed to be changed, and bad code causes bad code. – Jimmy Hoffa Oct 26 '12 at 15:53
  • @JimmyHoffa That could be part of software rot - it's not formally defined anywhere that I could see, so my examples may be incomplete. It doesn't seem like it would fit into software entropy, though, since all of the discussions about that involve actively making changes to the system. – Thomas Owens♦ Oct 26 '12 at 16:01
  • Yeah I agree; I was referring specifically to rot, your definition of entropy is spot-on with my understanding. – Jimmy Hoffa Oct 26 '12 at 16:03
3

It could mean that, the more you add functionalities to your software the lesser its design stays clean, elegant, and further extendable - meaning at some point, you have to rewrite / refactor substantial parts of it?

Improve this answer
0
2

Over time there are many things that could happen to a code base that could cause it to deteriorate.

  • Multiple developers, of different skill sets editing the codebase.
  • Coding standards not being adhered too.
  • Architecture design patterns being used ignored to get quick fixes in

These could all lead to what could be called wear and tear of software.

Improve this answer
1

It is true in the strict sense that the software itself does not wear out. But everything else about the entire process of deploying, configuring, and using software does go through changes that can have the same effect in the impression of the user. You've listed some of them already. Others include:

  • Configuration: the software that worked well when running as a pristine install may start to behave unexpectedly or even exhibit defects that were not visible at first by the time users have finished tweaking the installation the way they want. Just think of the Windows registry: the richest, most powerful software company in the world is unable to reliably diagnose problems arising from too many or conflicting configuration settings in the registry; standard operating procedure is to tell the customer to reinstall the OS rather than spend more than a minimum time trying to fix it.
  • User expectations and habits: using the same program for any length of time habituates the user to the way it works. What was initially new and exciting becomes normal. This can work for the product, as users learn the quirks of operating things that they initially considered confusing, but it can also cause accumulating misgivings that eventually culminate in hatred.
  • data load: the longer a program is used, the more data it usually has to deal with. Views, reports and procedures that were acceptably fast in the beginning often degrade in performance the more data they have to deal with, until the run times for typical tasks that were once acceptable become unusably long. Again, technically this simply exposes a defect that already was in the software from the beginning (and proper load testing would have aught it), but the impression on the users is one of "wear": "It's soooo slow now!"
Improve this answer
1

Many factors can conspire against a program that is considered acceptable, good, or even great to erode its reputation and ability to perform its function.

  • That was then, this is now. I visited a museum in Chicago and saw the control panel in an Apollo space capsule. At the time, it was state of the art, the best available technology. By our standards today it would be considered to have poor human factors, clunky old switches instead of a touch screen. Its computer was tiny and slow. Brilliant minds created it, with some aspects of their design being completely original with no previous model to imitate.
  • Bowie knife to Swiss army knife. When it was made, it had one feature and did it well with great ease of use. It might have come in just one color (black), but it was solid and replaced a time consuming manual system that people still remember (and hated). Over time, new versions added complex features and options. People forgot how little the manual system did and how hard it was to use, but they are seeing hard to use again and don't like it.
  • The integrity of the original design is compromised. When originally fielded, the design might have been based on a clear, simple design. For example, in the name of improvement, the thousand line C program that had a function per feature was replaced with a C++ program that was recoded, but not rearchitected.
  • Orphans can get kicked around. The original authors and original stakeholders had some goals relative to functionality, scope, return on investment, suitability for a particular purpose, and probably most importantly, the software was of high priority. Once in maintenance, sometimes the level of resources, the amount of focus, the clarity of purpose, and the ownership and empowerment of the stakeholders floats. The new people know less than the original people, fail to respect their written or unwritten contracts about the software, and may make quick and dirty or slow and expensive changes, quickly earning disapproval from QA or resource/project managers.
  • Moore's law. If software was built to the limits of hardware (say 640K RAM of RAM and 10 MB hard drive), a few years later it may be remembered with nostalgia, but it is a relic.
  • New paradigms. Pocket PC software that didn't link apps with other apps can't be nearly as versatile as an app that feeds its intents into a user selection from among several different programs (think photo sharing on an Android phone or tablet). That text based terminal with menus selected by typing a number and hitting enter is no match for an effective web page, not just from easy of use, but for inter-connectivity, scalability and maintainability.
  • Competitive new designs shine by comparison. Being first can be a hard road, and to paraphrase Newton who said he stood on the shoulders of giants, it can be painful for software if it has competitors standing on top of it. Software that stops growing and improving is like people who stop growing and improving. The Honda Accord has been a Car and Drivers magazine top ten pick for over twenty years, but few people would pay the new car price for a brand new copy of a twenty year old car (except maybe a Brazilian build VW bug). In software, the problem is amplified because prices drive downward for many software based products.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.