Software RULES!

Without software the computer revolution would be nowhere. Software does rule the computing world.

Software Rules

  1. Software is a tool, not salvation.
  2. Management will buy software as a salvation.
  3. No software is TURNKEY.
  4. Management believes all software is TURNKEY.
  5. The software you use always looks buggy.
  6. It is always easier to blame the software for work problems than pointing out real problems to management.
  7. The software the salesman is showing you always looks bug less.
  8. The more complex/integrated the software, the more bug fixing becomes a magic art.
  9. In order of increasing magnitude there are:
  10. User friendly software often lacks enough power to do your job.
  11. User friendly software is sought after by management to keep training costs down.
  12. Any command that needs more than 4 pages of documentation should be termed 'USER HOSTILE'.
  13. Any command with more than 1 page of documentation will only be used as a last resort.
  14. Speed is proportional to the time you have to wait. It doesn't matter if the new software does 10,000 commands in 30 seconds versus 1 command in 2 seconds with the old software. The 30 second wait is longer than the 2 second wait , thus the new software is slow.
  15. Salesman are often taken at their word, while everyone else has to prove it.
  16. Good training leads to remarkable pay back on computer use.  (Story)
  17. Software training budgets are the last thing funded, and the first to be cut.
  18. The longer you evaluate software, the more outdated it will be by the time you use it.
  19. Customer driven software is great for the short term only.  (Story)
  20. Innovation beyond customer needs and wants is the only way to stay ahead in the market.
  21. Customers that know the least about the software make the most demands.
  22. Customers that know the most about software make important demands, but are often not recognized because they are too busy working, not complaining.
  23. Software can not change a companies policies, procedures or structure. That is the job of leaders.
  24. Software is often purchased to change a companies policies, procedures or structure.
  25. Software organizations need leadership, not management. Software groups must be lead through constant changes, not pushed.
  26. All software becomes outdated on the date of purchase.
  27. Software Revision' is a better strategy for making money than 'Planned Obsolescence'.
  28. Sales forces are the ones that decide what is to be done with software. Unfortunately sales forces wouldn't know innovation if it hit them. (See rules 19 & 20 )
  29. The only time a System Administrator is recognized is when there is a problem. A good System Administrator is a natural hermit.
  30. Maintenance contracts for software will expire the day before you find a critical bug.
  31. When a fix for a software problem is not obvious, the problem is blamed on the hardware. (See Hardware #9 )
  32. Software is often purchased by the people who don't know how to use it, but are buying it in the hopes someone will know how to use it.
  33. Users groups are most often attended by managers, not the users.
  34. Whenever software is updated, hardware must be updated also. (See Hardware #6 )
  35. What works doesn't always sell, what sells doesn't always work.
  36. Software that is 'better' or much 'better' is not beneficial. It has to be significantly better to pay for change.
  37. Software decisions are often based on minor differences that are seen as major improvements.
  38. One fact does not generate wisdom. A software salesman will take one fact and try to make it a religion.
  39. Advanced or Automated software requires an advanced user. Even if all he does is push a button 99% of the time. Knowing what to do the other 1% of the time requires a user who understands fully what is going on.
  40. Automation in the hands of an advanced user has significant pay back. Automation in the hands of a novice rarely shows pay back. Automation just adds to the tasks a novice must learn and retards the learning of skills needed by the novice.  In short automation for dummies is dumb automation. (Story)
  41. When no one reports a bug or complains about software, one of the following is true:
  42. Any programmer that claims the honor of writing perfect software will be given nicknames by his co-workers. None of which could be repeated in polite company.
  43. For software to be responsive the 'Minimum Hardware Requirements' listed for the software must be doubled. This includes memory, disk space and cpu power. If graphics are involved, requirements must be tripled.
  44. Software that requires training of the users will be loaded immediately without training. Software that requires training for the system administrator will be loaded after training is complete and only as a last resort, if ever.
  45. One simple accurate example is worth 10 pages of documentation. Examples are rarely used in documentation. Those that are used are often inaccurate.
  46. The enhancement or bug fix you need is always in the next rev. (See Software #27 )
  47. Software enhancements cause new problems equal to or greater than the problems the enhancements fixed.
  48. Software can not invent solutions.  Software can not be forced to be successful, no matter how much screaming, ranting, raving, pleading or promising is done. Software can only be made to do what a company or individual is successful at doing now.
  49. Software quality is defined by the customer, not the provider. The provider can meet the customers expectations, but can not define expectations.
  50. Software systems must be maintained. This includes programs, databases, user interfaces, documentation and training. Software left unsupported will soon become unreliable, useless or unusable. The more complex the software, the faster the demise.
  51. The quality people will accept when buying software is often amazingly lower than what they will accept buying anything else.
  52. Any software solution can be provided given time and money. The problem is most people don't ask how much time and money.
  53. When software bugs are reported, the standard operating procedure is:
  54. Beta testing makes users feel good, but does nothing for quality. Quality is a result of design, not testing.
  55. The lowliest human is better at adapting and making decisions than the best computer program. The only exception is when a human is following government regulations.
  56. Updating any software will require you to update all software. This is detailed in the 'Continual Purchase' clause of all Software contracts.
  57. Poorly planned software requires a genius to write it and a hero to use it.
  58. The demand for geniuses and heroes is constantly growing in the software world.
  59. Write crummy software and have friendly energetic people on the help lines.  Everyone will think you are wonderful even if they can't get anything to work.
  60. When you find yourself getting friendly with customer support after many days of constant contact, relax it is just a case of  "Stockholm Syndrome".  You are beginning to bond with your oppressor.
  61. Quality and ease of use are nearly as important as advanced function.  While ease of use may save you minutes, advanced function may save you days of work.
  62. Software companies that rely on customers to do software testing do not understand their customers need.
  63. A week on the keyboard may save an hour in the manual.
  64. Everyone wants to use a database, but no one wants to pay for creating and maintaining a database.
  65. Only after you discover a software package's flaws, shortcomings and limits can you maximize it's usefulness.
  66. Management driven software is often written to support an obsolete processes.
  67. Coding isn't done until the documentation is done.  If you don't document what you have done, you have done nothing.
  68. Critical deadlines or demos will reveal new problems (Story)
  69. Large software companies rarely have problems with software development.  There isn't enough to worry about.
  70. The best way to invigorate the sales staff and demoralize customers is to announce software releases months or even years in advance
  71. The worst bug of all is a specification that doesn't meet customer needs.
  72. Lack of time, resources or money pale in comparison to the effect incompetence has on quality.
  73. Embarrassment is more successful than logic when trying to get a bug fix.
  74. A diligent customer takes 4-12 hours to isolate, define, document and describe a bug so it is understandable to the company that created it
  75. When you spend money to make incomplete or buggy software, you just paid to drive customers away.
  76. Buggy, incapable or poorly supported software is the most costly software you can use, even if it is free.
  77. Software can not fix chaos, throwing software at chaos will be ineffectual.  Only after you have brought order to chaos will software be helpful. (Story)
  78. Interfaces built on simplified data will simply not be useful.
  79. Do silly things in software and you can add many un-enjoyable hours to software development and support.  Example: Allow a space in directory names to add millions of hours to software and script development every year.
  80. Yesterdays costs will be tomorrows cost unless you make an improvement.
  81. Amateur software works for me
  82. Professional software works for the customer
  83. Drivers for enhancing or correcting software, in order of increasing magnitude:
    1. Value for the customer and market superiority position
    2. Software developers vision
    3. Sales forces misunderstanding of the customers needs
    4. Sales gimicks
    5. Directives from managers who don't use the software
  84. Twisted Definitions of words describing software.
Home Page © Val Hubbard copyright details.

 Version 2.6

 Software Rules last updated Jan 5 2022

Software page last update Jan 5 2022

These rules do not reference any specific person, company or software package. They are comical exaggerations of the occurrences of everyday life in the field of software. Any relation to events anywhere past, present or future is entirely coincidental.