• About
  • Drafts
  • Sample Database SQL
  • Selected Posts

Bradley Ross' Blog on Life and Computer Software

~ What I've learned in IT

Bradley Ross' Blog on Life and Computer Software

Monthly Archives: August 2014

Why My Code Works

28 Thursday Aug 2014

Posted by Bradley Ross in Atitudes, Software Development Life Cycle

≈ Leave a comment

Tags

development guidelines

My code works, and I’m not satisfied until the user is satisfied.  I’m not saying that I’m a miracle worker, but I do have a number of principles that have enabled me to succeed where others have given up.

Understand the user

I started in engineering and have worked with management,  software development, research, operations, sales, and a variety of other groups.  It may take a little work, but you can eventually get them to tell you what they want.  It amounts to getting their work done faster and with less effort, making customers and management happy, and avoiding surprises.  There are differences, but there are far more similarities.  Also remember that the developer will have an easier time understanding the user than the user will have understanding the software.

When the user describes what he thinks is a bug, listen.  When working in the chemical industry, I often found that the operators were correct about what was happening, even if they were wrong about why it was happening.  “He yelled at me” is not a good reason for not listening.  I usually take it as a sign that he cares about whether things work, and he will yell a lot less if I listen to him.

Know what’s easy and what’s difficult

One of the biggest problems that I have seen when communicating with users is that they don’t understand what’s easy and what’s hard in the development of software.  There are often things that are easy to do in the software but very difficult for the user.  There was one application where the mail room received multiple copies of a few dozen reports and they had to create packets for each of the recipients.  I changed the software to collate the reports by recipient and the mail room was ecstatic.  It only took me a few days but it saved them weeks of effort.  They didn’t realize that the reports could come off the printer sorted by recipient.

On the other hand, some things are very difficult to do in software, such as voice recognition software and character recognition for handwritten notes.  If you explain the problems, you may find that the requirement is not as important as originally reported.  Furthermore, there may be an alternative that’s easy for software to carry out and still meets their needs.  For example, it would be difficult to extract the “From” field on hand written notes sent via facsimile.  On the other hand, the computer can sort them by the telephone number of the fax machine that sent the note.

Use your experience

I’ve been working in software for many years and have seen many problems.  There are very few that are entirely new.  A fellow programmer was having problems with a program that was going into an infinite loop and asked for my help.  I took a quick look at the program, pointed to a line and asked him if that was what he really meant.  He looked at it, and asked how I could have read the program so fast.  I told him that I didn’t know what the program did, but the line was a complicated mass of nested arithmetic and logical operations, and that was where errors resulting in infinite loops were usually found.  I had a few other cases where the other person was amazed at what appeared to be magic.  In almost all of the cases, my explanation was the same:  that was what the problem was the last few times I encountered it.

If your experience can’t solve it, ask others.  Don’t be afraid to let people know that you need help.  In one case, I asked for help with an algorithm for processing medical data.  When I explained how my code worked, he said that I was using the wrong reference value for one of the measurements.  When I followed his suggestion, I obtained the correct answer.  It turned out that there was an error in the reference documentation for the equipment.

In another case, a magazine article mentioned how there was a requirement that an equipment room be accessible in an emergency, but entrance had to be prevented at other times.  (The employees were using it as an unofficial smoking lounge.)  The article went on to state how it was impossible to satisfy both requirements, a statement that I found hilarious.  You simply put an alarm on the door.  People know that opening the door will set off the alarm, and they won’t use it unless it is an emergency.

Not a perfectionist

I am not a perfectionist.  I merely want a close enough approximation such that nobody else can tell the difference.  It’s actually not as difficult as it sounds.  Management will sometimes tell you to only handle the serious problems, but there is no way to tell with certainty which problems are the serious ones.  There was a program that could be compiled for two different computer architectures, but it was only working for one of them.  I found an addressing error in the code that caused it to crash on one system but didn’t cause any noticeable problems on the other.  When I fixed the bug, it worked fine on both systems.  The problem is that I don’t know if the results were correct on the system where it was working.  Ignoring error messages has been known to cause deaths in some situations.  (See Therac-25)  If  web application crashes once a week and has to be restarted, do you really know what happens when it crashes?

When I code web pages, I turn on the development tools that lists all of the errors in the code, even if it is able to continue.  You would be amazed at how many errors appear, most of them being typographical errors in JavaScript code and tag attributes, which are easy to fix.  However, the results of these errors are unpredictable and undefined.  A change in the version of a browser can suddenly cause the web pages to fail completely.

It may be that time constraints prevent you from fixing some of these problems.  However, they should be noted and fixed when you have the time.

Religious fanaticism

When you design a database, there are some rules called Codd’s Rules of Normalization.  Sometimes you have to break the rules in order to improve performance.  I remember a heated debate with a database “expert” who argued that you always follow the rules even if it renders the application non-functional.  This is what I call religious fanaticism in software engineering.  (By the way, data warehouses are a violation of the normalization rules.)  I am not a religious fanatic.  In this case, I believe that the reason for the violation of the rules should be stated in the documentation, together with possible problems and how they should be handled.

Other fanatics will specify the use of frameworks or software libraries because they feel that that is the current technology for all applications.  Using a tool or method because other software components work that way may actually be justified because it limits the number of packages for which the maintainers have to maintain proficiency.  However, using packages such as Spring, Struts, JavaServer Faces, Facelets, or the current fad of the day because it is the current fad of the day is rarely a good idea.

Fanatics will also tend to mention things like agile programming, extreme programming, Six Sigma, and the SEI’s Capability Maturity Model as if the proper incantation of the mystic rituals will achieve success.  These are frameworks for thinking about processes, and, in my opinion, the key word is “think”.

Look for tools, not solutions

I will often use Google or go through my reference books to find a solution to a problem.  However, I don’t really expect to find the solution.  What I expect to find are the tools that will enable me to build a solution, and I keep looking until I find them.  That is how engineering really works.  The reason that most people give up is that they can’t find a solution and using the tools to build a solution is hard work.  When you look at it, the engineering process works for both bridges and software and can be thought of as having the following steps.

  • Observation – Collect relevant observations about the problem
  • Decomposition – Break the problem into smaller pieces
  • Analysis – Examine the pieces and how existing tools can deal with them
  • Synthesis – Construct a design for the solution
  • Implementation – Convert the design into a solution
Advertisements

Actual Requirements

26 Tuesday Aug 2014

Posted by Bradley Ross in Software Development Life Cycle

≈ Leave a comment

Tags

development guidelines

It has been said that a journey of a thousand miles begins with a single step.  However, unless you have a compass and a map, those first few steps are unlikely to get you nearer your destination.  However, following the map without question may also fail to get you to your destination.  There have been a number of cases where truck drivers have blocked traffic by ignoring clearly marked height and weight restrictions.  The police have been generally unimpressed by the statement that the driver had to keep going because that was what Google Maps or Mapquest told him to do so.

When creating a software application, the requirements document can serve as a map showing your destination and how far you have to go.   However, there can be problems.

  • I have encountered people who ask what we have to do so that we can declare the requirement has been satisfied.  My attitude is that you look for what has to be done to satisfy the requirement.  (Some people really don’t see a difference.)  They assume that they can convince the user that the requirement has been met, even though it hasn’t.  If the statement comes from your manager, you may not have much of a choice, but don’t be surprised when the user isn’t happy.  If you can’t meet a requirement, you have to deal with it.  Determine the impact of not meeting the requirement and see what you can do to either meet the requirement or reduce the impact of not meeting the requirement.  At the very least, don’t let it catch him by surprise.  (Surprises are very unpopular.)  The user may decide that the requirement can be eliminated or replaced with   with something else.
  • In addition to the requirements in the document, there are many implied requirements.  These are the requirements that seem so obvious, they don’t need to be said.  However, that being said, it is probably best that they are said, and you should consider adding them to the requirements list.  An example might be having electrical power and an internet connection where the computers are to be located.  Even if it isn’t your requirement, it is somebody’s requirement.  (When I informed one user that I couldn’t install a computer system because there was no internet connection in their building, they informed me that I should stop by the stock room on the way over and pick one up.  This is the equivalent to installing an electrical outlet without having it hooked up to power.)

When I look at an application, I think about the abilities of the software.  Whether or not they are in the formal requirements document, you want to think about these things.  I have listed a few of the items below, and you may find these items useful.

User oriented

I’m not a perfectionist when it comes to user demands.  I merely desire a close enough approximation so that the user can’t tell the difference.  It’s actually easier than you think.

  • Capability – There is something that the software is supposed to do.  Does the software have the capability to do it?
  • Usability – Is the user able to use the software to do his work?  Does the software have built-in documentation, or does he need to have a manual ready when he uses it?  (If the user needs to have a few manuals sitting next to him, that says something about the lack of usability.)
  • Flexibility –  Does the user have to change how he does work in order to use the software?  Can different users operate the system in ways that are convenient for them?
  • Likability – Does the user feel comfortable using the software?    After a few hours, do you hear screams of despair from his cubicle accompanied by the sounds of breaking pottery?  (I am speaking quite literally here.)
  • Verifiability – After carrying out a task, is the user able to verify that he did it correctly?  This will go a long way towards user satisfaction.
  • Reliability – Will the system be available when the user wants it?

Maintenance oriented

Things will go wrong from time to time.  If the system can’t be fixed, expect problems.

  • Understandability – Can the people who maintain the system understand how it works?  Is it well documented, including the source code and the instructions for the software builds?
  • Traceability – If something goes wrong, can the people maintaining the system identify the piece of code causing the problem?
  • Audit-ability – Can the people who maintain the system verify that it is actually doing what it is supposed to be doing?  If it isn’t doing the right thing, can they determine what it is actually doing?  If there are operational problems, are the operators informed or must they wait for the sound of angry users?
  • Restorability – If the system crashes, can it be restarted?  Can it be verified that the restart doesn’t introduce errors?
  • Survivability – If unexpected events occur, will the system keep running?  What happens when there are network problems or an unexpected load on the system?
  • Administrate-ability – Can the operator make administrative changes to the system or do they require changes to the code?
  • Isolatability – Can changes be tested on a test platform before being placed in production?  (Isolating the development, test, and production environments.)

Change is a constant

I have frequently heard that there will be no further changes to a system.  However, there are always more changes.

  • Modifiability – How hard is it to make changes to the system?  For example, how hard is it to change the database used by the application?  What is involved in making changes to the wording of menus?  Can the system be moved to another platform?
  • Scalability – If the workload increases by an order of magnitude, what is required to keep it running?
  • Mobility – Can the software system be moved to another system, and how much effort is involved?  I was involved in one set of applications that hard-coded the IP addresses in the software.  When the network was reconfigured, the IP addresses had to be changed, and they had to change all of the code for the system.

 

 

 

Advertisements

Subscribe

  • Entries (RSS)
  • Comments (RSS)

Archives

  • April 2018
  • February 2017
  • January 2017
  • August 2016
  • July 2016
  • May 2016
  • April 2016
  • June 2015
  • February 2015
  • September 2014
  • August 2014
  • July 2014
  • March 2014

Categories

  • Atitudes
  • DailyPost
  • Finding Information
  • Retail Support
  • Social Media
  • Software Development Life Cycle
  • Uncategorized
  • Wordpress

Meta

  • Register
  • Log in

Archives

Categories

  • Atitudes
  • DailyPost
  • Finding Information
  • Retail Support
  • Social Media
  • Software Development Life Cycle
  • Uncategorized
  • Wordpress

Meta

  • Register
  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.com

Create a free website or blog at WordPress.com.