What makes good software?

I have seen many implementations of good software.   However, the reality is many major applications cannot be supported after 3-5 years.   In the CAD industry I have seen "rewrites" be the way to do major updates on software.   It takes time, is costly and often is no more sustainable after 3-5 years as was the original code.  I have also found even minor bug fixes can not be done after 18 months to 3 years.  The ability to understand and fix the code has been lost.

Traditional methodology of software was a huge release of software every 18 months.  Developing new applications may take 18 months.  By the time it is in the users hands it is obsolete and no one remembers what was done.  One Siemens NX developer stated, "by the time it was in the users hands it was already obsolete".

Agile software development is the modern method.  Validate the plan with users then get core, quality code into users hands early.  Then keep building.  This is NOT alpha/beta testing but a plan to have users verify that the code is on target every step of the way.   Agile software development REQUIRES that quality design and coding methods must be followed. It will fall apart otherwise.   I have seen Agile software development transform Siemens NX development.

There are ways that software can be measured.  There are CMMI standards, but not everyone knows these.  If you have the ability to investigate this do so.   My quick interpretation of the standards 1-5

1. You can prove who wrote it.  I call this hero worship.

2. You have control of the code.  Documentation is done, standards are set and followed.  This is a major change in many companies and to get to level 2 and beyond takes a lot of work.  It needs to be in the software design from the beginning.

3. You can validate the code.  Not just test, but validate it works. The customer must be involved for true validation.

4. Customer needs are met with the software.   The customer is in the loop.

5. Working to meet STRATEGIC needs of the customer.  

I have seen software groups working to level 4 and 5 standards.  The payback is huge.   Sadly a majority of software I worked with over 40 years was written to a level of about 1.5.  High cost to maintain and fix and within a few years became un-fixable.   I have seen where companies mis-understood the work involved.  When they were rated a 1.5 they promised to be at a level 3 in 9 months.   They didn't make it in 3 years, if ever.  To go from a sub level 2 to to a level 3 or above normally requires a total rework of habits and practices of everyone in the software company.  It can be done, but management must have the vision or desire to do the work.  This type of change takes leaders, not management.

What do I recommend? When I first learned to write software, basics were taught.  Not well taught were the more important things that make code sustainable and quick to adapt over years.   The one important thing  I learned well was writing out the algorithm BEFORE coding.  Plan then code.

Good software must be Designed and planned and the plan validated.  Then document the design.  Document the code.  Make and follow coding standards. Create accurate document for the user using examples and video documentation if applicable.  Always validate the code is meeting customers needs.

Design and plan the software Writing while designing wastes a lot of time.  Document the plan, functions, flow and more.  Biggest error in software is missing the customers needs.!!!  Validate with key customers before coding.

Document the code  One sentence can save hours of interpretation.  Every routine, loop, and variable should be documented.   Yes this takes a little longer, but it improves the code.  As the documentation is written many errors are found and corrected early.   Code needs to be documented so well a 12 year old could read it and understand.  Then it can be quickly and correctly understood.

Establish and  follow standards

• Naming standards for variables, document what the variable is for when declared.  Declare EVERY variable.   When we had to interface with outside software we defined all of our variables with a company name abbreviated as the prefix to the variable.  If we had not done this, determining our changes vs. other changes would have become impossible.
• Error collection and reporting standards.   Use error capture routines to grab errors and correctly report the problem.  Use them in every routine.  This will help you catch user errors and mis-match of routine calls and variables passed. 
• User interface are you checking input for valid data ranges.  Is the user interface method consistent.    We had a software application that wanted percent as an input. In one part of the application, the number 0-1 was used for 0-100.  In another part the user was supposed to enter 1-100.  In both cases there was no input checking and the users would enter .01 where 1 was needed or 50 where 0-1 was used.  The software would go off for hours merrily trying to use the invalid values.  In 10 years this was never fixed.  It was never seen as a problem in software design, but it was a problem for every user.
  
• Data array design.  What are the fields and mapping.   Is it documented so another programmer understand it in seconds.
• Reuse of code.  The goal is the code can be re-used  by all developers and through generations of updates. not a one shot deal.    When standards are not followed, developers often re-write their own versions.  A waste of time and leads to bloated code.

There must be a system to Control the software.  Check in system, backup previous versions.  Everyday the work is backed up. 

Validation  Testing does not guarantee validation.    Agile software development stresses validating software with customers.   Validate the plan and then validate the result with the customer.

Many complain the documentation and tight standards takes too much time.  It does take more time in the front end, but not an excessive amount.  Once you are in the habit, it is quick.  Over months and years it saves much more than it cost.  It may even save the software company.

For  40 years I have used the number that was researched in the 1980s for predicting software creation.  400 logical units per man-month. In advanced languages that is almost equivalent to lines of code.   People have told me they can write thousands of lines of code a day!  That is true, but it is not integrated, documented, debugged and released.  When the work is done and everything analyzed, Hundreds of projects I have seen confirms this number is accurate.
 
First time I analyzed software development was for a project in college.  I talked to the creator of a database search program.   He had been working it for 5 years.   He was sure he averaged thousands of lines a code a month.   He estimated there were 25,000 lines of code in the program.  Divided by 60 months, it was 416. 

At a software release the company spokesperson was bragging they had done almost a million lines of code over 18 months with 250 programmers.   I ran the numbers in my head and realized it was under 250 lines per programmer/month.  They had under performed badly.   I asked their software Development VP what happened when the budget had been over-run by 35%.  He looked stunned and asked who it was that told me about the cost over-run.  I told him the speaker had given me the numbers and it was a quick analysis.  He just asked me not to tell anyone about the overrun. He did not ask for the details of the analysis.

This 400 number is not set in stone.  It was derived from the way software development is done on the average.   I was in a group writing software for 4 years.  We used all the design and documentation rules I listed above.  We averaged 1200 lines/person/month.  3x the normal rate.  The customers were very happy with the code and it ran for 10 years with only 2 minor bugs found.  A software analysis group was going through the company doing CMMI software evaluations.  At the time CMMI evaluations were new. Most all of the evaluations were a 2 or less out of 5.   When they evaluated our area, they gave us a qualified 4 out of 5.  Qualified since we didn't have a tracking/backup system for our code.  Management had not seen the cost benefit of such a system since our need to change and fix things after creation was very small.

Dr Nelson P Repenning of the MIT Sloan Business school.   The capability gap as it relates to software.

CMMI software standards and measurements.

Happy Computing, Oct 22 2024

Back to the software rules page