Light Software Development - Best Practices for Tech-Savvy Business Professionals

This article is intended to be a crash course on standard processes and best practices for tech-savvy business professionals who also perform light software development.

Many business offices have a tech-savvy professional who assists with some “light” software development in addition to their regular job. This light software development may consist of things like: Excel fancy spreadsheets and macros, SQL queries, reports, small applications, Web/HTML pages, Microsoft Access applications, Windows scripts, Perl/Python scripts, Robotic Process Automation (RPA) scripts, or “Screen Scraping” programs.

This light software development is often supplemental to IT support, who are more focused on the “big systems”. Light software development can be a huge productivity boost, while waiting on IT support to develop more permanent enhancements in the “big systems”.  

Background Part 1 - Software Development “Waterfall” Model

In the “old” days, the typical software development process utilized the “Waterfall” model. This was a linear model usually consisting of the phases: Requirements, Design, Coding, Testing, Implementation, and Maintenance. This structured approach was obviously better than just jumping into writing code on day one, which developers are often tempted to do. The name “waterfall” came from the concept that you could start one phase as you were finishing up the previous phase. In large software development projects, there was often separate people or groups assigned to each responsibility. When their phase was completed, they would “throw it over the wall” to the people responsible for the next phase. Despite many efforts to improve the quality of work in each phase, the Waterfall method was eventually determined to be the wrong method to use due to its inherent weaknesses. The problems with the Waterfall model include:

• Little involvement with the end-users
• Poor communication between stakeholders in the project
• Many requirements were not identified up front, and/or original requirements changed or became unnecessary
• End-users had to wait a long time before they ever got to “touch” the software
• End-users did not like the software after they finally got to use it
• Often, many systems that had taken a lot of time and money to develop went unused and the projects turned out to be complete failures

Background Part 2 - Software Development “Iterative” Model

A different paradigm came about that addressed many of the weaknesses of the Waterfall model. It has different names, “Life Cycle”, “Spiral”, or “Iterative”, all referring to basically the same process. The Iterative model basically includes the same phases as the Waterfall model, but repeats them multiple times throughout the project. The idea is to break the project into multiple iterations, with each iteration adding new features or components to the system. For example, the first iteration could start with the core component(s) of the system and then each iteration would expand on the various features that all depend on the core. Or another approach - the first iterations could start on some of the “easy” features of the system to implement, and the subsequent iterations could expand into the more complex features of the system. Some iterations can simply consist of creating a semi-functional “prototype” so it can be put in the users’ hands to get their feedback before the prototype is fully functional. The unique characteristics of the system can be used to determine where to start and how to proceed. The main benefit of this model is getting the software in the user’s hands earlier. This greatly improves the communication between the users and development team. Feedback is gathered, and tweaks can be made. These tweaks basically add one additional phase at the end of each iteration, which could be called “Refactoring”. Refactoring can include changes requested by the user, or modifying the internal workings of the software so it can handle the current features as well as the new features being added in the next iteration. The Iterative model assumes the project cannot be planned perfectly from the beginning, that requirements will change, and communication breakdowns will occur but can be corrected. Benefits of the Iterative model include:

• Increased communication with end-users
• Fixing problems or making requested changes sooner in the process
• More buy-in from the users
• The end-product is something the users are already familiar with so it should satisfy their requirements and get used.

Background Part 3 - “Agile Programming”

Agile Programming is basically a term describing the Iterative model but expands it a bit further. Agile really emphasizes face-to-face communication among the project stakeholders. It makes a point to include representatives of the end-users in these frequent discussions, which really makes them part of the project and critical to its success. Often the project team, including the end-user representatives, are moved to the same physical location, such as the same floor in a building or same work area on the floor. This will force the end-user representatives to take more time out of their “normal” job to be dedicated to the project. The development team will make fewer wrong assumptions about the end-users’ needs. This will also aid in the decisions about which features to implement when, and which are most important if the project is in a time crunch. Key characteristics of Agile Programming are:

• Communication
• Adaptability and flexibility, rather than predictability
• Speed
• Quick, short iterations

Light Software Development Process for Tech-Savvy Business Professionals

Tech-savvy business professionals already fit into some of the characteristics of the Agile process. We are not a software development shop. We are process improvement professionals residing in the same area as the end-users. We already are (or should be) very familiar with the end-users’ needs and business processes. We work with the end-users on a frequent basis, and should have effective communication with them.

The Iterative model should be the preferred model for us for several reasons. First, because of the inherent benefits of the Iterative model vs. the Waterfall model. We will produce more effective software systems by breaking our projects into multiple phases, putting the systems into the users’ hands in order to get their feedback and make the necessary tweaks. But also because we are not professional software developers. We realize that we cannot write the perfect code. We do not have the testing skills that a typical software developer would use in order to eliminate all the bugs from our systems. It will not be perfect the first time because we are new to all of this stuff and it is not the primary purpose of our jobs in our business office. Due to those limitations, the iterative model makes a lot of sense. By putting the software into the users hands, the user will aid in the testing process, and the users will realize the software will not be perfect the first time. As we do our tweaking and refactoring during each iteration, we will have the opportunity to go back and “clean up” our code as we gain more skills and knowledge about programming. Finally, this method works well for us “politically” because our progress can be seen. We will continuously be providing more features to our users, as opposed to “hiding” back at our desks for long periods of time when management would be wondering if we are really doing anything.

The decisions about how to define each iteration, and the iteration priorities for a project will obviously depend on the project itself and the people involved. Sometimes the business need or management decision will determine the priority. As mentioned above, sometimes it makes sense to start with the most difficult pieces first, or the easiest pieces first. Sometimes the order is not important. But to reiterate, the point is to establish communication with the end-users, get buy-in and participation from them, get the software in their hands in order to get effective feedback, and re-factor or “tweak” the system in each iteration to expand the functionality and also improve the quality of the system.

Testing

As mentioned above, it is a given that tech-savvy business professionals are not professional software developers, we are learning how to program as we go, and we will not always produce the highest quality software. However, we should still make our best efforts to put out the best software we can. From the user perspective, the level of quality is best displayed by the frequency of bugs (errors) occurring in the system. We should always make our best efforts to test our software as thoroughly as possible to identify and fix all errors prior to handing it off to the users. The quality of our performance, skills, and professionalism will be reflected in the quality of our software applications.  Even if we are personable, hard working, smart, and creative, it will still reflect poorly on us if we put out “buggy” software. This means taking a devil’s advocate approach and assuming what can go wrong will go wrong. We should:

• Do our best to think of abnormal situations that could occur and program the system to handle those situations.
• Assume that a user WILL enter information incorrectly or use the system incorrectly.
• Implement validation on all data input forms to catch invalid input and tell the user what they did wrong. When coding input forms, write the input validation code before you write the functional code that happens after the validation.
• Put all code within Try/Catch or “On Error GoTo” blocks in order to handle the errors and display error messages, as opposed to allowing errors to crash the program.
• When integrating with other systems, assume the other system will provide unexpected results, and program our system to handle those situations.
• Conduct unit testing – thoroughly test a “unit” of your code before going on to the next “unit”.
• When developing applications that calculate or display numbers (which is very common in Accounting) assume the numbers will be wrong. Go back and verify all details, subtotals, totals, etc. and identify where numbers have been miscalculated. This will occur often. Often this requires cross-referencing the numbers with the totals from another system or report to make sure they “tie out”.

These are just a few suggestions on how to go about testing. But the main point is that testing is a frame of mind you must have.  You should always assume that you made mistakes the first time you wrote the code, and testing is absolutely necessary in order to go back and find those mistakes. It happens, and is necessary even for the best of us.

Documentation

Just like testing, documentation is especially necessary for tech-savvy business professionals because of the same reasons (we are not professional software developers, we are learning how to program as we go, and we will not always produce the highest quality software). Also, our business office may have a high turnover rate, so documentation is key to continuity. Documentation is critical for maintenance and enhancements to applications. Even if the maintenance is done by the original author of the code, documentation is just as necessary, because the developer can, and will, forget what he/she did yesterday, and why. Because we are amateur programmers, we won’t write the highest quality, most efficient, or most ideal code. This is a given. What is more important than writing the best code, is putting comments in the code explaining what is going on.

• The two types of necessary documentation are: 1) comments within the code, and 2) overall application documentation - ideally stored in a “Documentation” folder/database/wiki space, etc.
• Make it a habit to go back and add comments to each section of code after it is completed (if you did not already add comments at the time you wrote the code). Do this again after you think you have finished the application. Go through all the code and review each section to ensure that adequate comments are in there to explain what the code is doing.
• Make it a habit to thoroughly update the overall application documentation after you have completed the application.
• Make these things part of your mental checklist and a necessary step in completing an application.