Quantcast
Close X

Writing Good Software

There are five major steps that make up our software projects.

Step One - Requirements

This is always the first step. The goal of Requirements is to identify:

  • the business problem
  • the functionality needed to solve it
  • a way of knowing when we’re done.

Depending on the size of the project, the Requirements step might be as simple as a quick phone conversation.  More typically, and certainly for larger projects, it may involve a team from Northwoods and the client that meets multiple times.

During the Requirements step, listening and asking good questions are both critical. The  deliverable will show that we understand the business issues. This feedback, for smaller projects, is often a simple confirmation via the phone or email; for larger projects, it is a detailed Business Requirements document that is reviewed and approved. During this step we also develop preliminaryhigh-level estimates for time and budget.

Requirements serve as a foundation for the rest of the project. At the end of the Requiements step, we will have identified some or all of the following:

  • goals of the project
  • features to be implemented
  • user requirements
  • system requirements
  • risks
  • assumptions
  • exclusions to scope
  • implementation considerations

The purpose is to establish high level understanding. Requirements avoid specific technical and functional details. (These are defined next during Software Design.) After the requirements are set, if enhancements or modifications are requested, they are quoted and scheduled separately from the main project.

This step is also known as DiscoveryBusiness Analysis, or Business Requirements

Step Two - Software Design

After the requirements are approved, software engineers fill in the details of exactly how they are going to program the software. It is a time for planning and problem solving. Depending on the size of the project, some or all of the following are considered:

  • Robustness – The software is able to operate under load or tolerate unpredictable or invalid input.
  • Usability – The software has an intuitive user interface (and is aesthetically pleasing too).
  • Security – The software is able to withstand hackers and hostile attempts to compromise it.
  • Compatibility – The software will not break anything, and is backwards-compatible with older versions.
  • Fault-tolerance – The software is resistant and able to recover from component failure.
  • Maintainability – The software is designed so future programmers can update the code.
  • Modularity – The software is built as well defined, independent components – making it more maintainable. Components are built and tested in isolation before being integrated. This allows division of work into teams.

For very small projects, Software Design often takes the form of an email that lists the tasks to be accomplished, the assumptions, and a timeline with budget.

As the project grows in size and complexity, we often create a detailed Software Requirements Specification or SRS. The SRS becomes the bible for the development team and the basis for all testing activities. The SRS contains: 

  • screen shots or diagrams of the new system
  • details of user interface behaviors
  • use cases of the behaviors of various audiences
  • detailed business rules and exceptions
  • preliminary database designs
  • data dictionary
  • equations, charts, and formulas
  • report layouts and rules
  • all details necessary for the development team to build the system

Along with the SRS, we deliver final estimates for project costs and timelines, and fully define all project deliverables.

In our view, the primary purpose of this careful planning is to anticipate and avoid potential roadblocks. This is particularly true as a project gets larger and the desired delivery period gets shorter. Our goal, and your goal, is to avoid surprises and misunderstandings.

Step Three - Software Programming

After the design is done, coding (programming) begins along with a number of other processes.

Programmers engage in weekly code reviews with peers. A code review is a brief “show and tell” where a programmer will present recently-written code on a big screen and receive peer feedback on coding techniques, known defects, coding standards, and style. Code reviews allow for the sharing of knowledge in both directions and are valuable for catching potential problems with scalability, modularity, and maintainability long before the code is completed.

All code is checked into our Source Control Database daily and run through a build server to ensure that all parts are present and that everything compiles.

We believe that happy programmers write better code, so we provide our programmers with all of the software tools they request – including Visual Studio Team Edition, a variety of XST and CSS editors, build servers, and test servers.

We provide them with multiple monitors, fast computers with as much memory as Windows allows, and allow private refrigerators filled with Mountain Dew. Most important, we provide an office with a door that closes so they can turn on tunes and get into a zone. There is a lot of evidence that getting a programmer into the zone improves productivity.

Good coding can happen at odd hours, so we set up secured VPN connections that allow programmers to tap in from home.

Programmers are responsible for unit testing. That means they are responsible for testing the code they write and making sure it works as specified in the SRS. In some cases, on smaller projects, they are also responsible for regression testing and integration testing. Once a program passes unit testing, it is passed off to the testing department.

Step Four - Testing

Software has bugs.

Even our most mature software programs absolutely refuse to deal with things that they weren't taught to deal with explicitly, and they tend to refuse in the most childish of ways. They babble incoherent error messages you don’t understand, and they do it at the most inopportune times – like just as you’re showing the boss the new software. Most of the problems usually come down to a single line of code somewhere with a tiny almost insignificant oversight in it – the programmer never imagined that anyone would ever enter a negative number in the payment field (it wasn’t in the SRS after all). Sometimes it’s just a typo, or a comma in the wrong spot. Given that most (non-trivial) software programs have thousands of lines of code in them, it is no surprise that bugs happen.

The job of our testing team is to find these bugs before you do.

Finding bugs takes a lot of time and a lot of hard work. Good quality testing takes about 20% of the time spent programming. Like good detective work, testing is hours of tedious leg work and occasional payoffs. Good testers push the limits – they push keys and enter numbers that no one would have thought of, and they exercise the software until it breaks. Then they record the bug in our bug tracking system, along with the steps needed to reproduce it, and continue their systematic pursuit of imperfections.

We use testers because programmers are the worst people to test their own software. Why? For the same reason most people are not good at proof reading their own writing. We all have blind spots that keep us from seeing obvious typos. We know what we meant to say, and we allow our minds to skim over words that we already know are correct – even when they’re not. Programmers get tunnel vision. They know how their programs are supposed to work and do not spend tons of time thinking of all the ways uninformed users might use their programs. And frankly, it’s really not their job. Writers need editors. Programmers need testers.

There is a healthy tension between programmers and testers. Programmers dream of delivering bug-free code so they don’t have to suffer the indignity – however modest – of having to watch their programs crash. But they are also secretly grateful, because they will receive praise down the line from happy customers when their program works as expected.

We employ full-time testers who have been trained in the disciplines of regression testing, integration testing, use case development, test plan development and test plan execution. 

We don’t want to pay for testing. For various reasons, some clients decline testing. This choice shifts the burden of testing from us to the client, but unfortunately doesn’t change the number of bugs. It only changes when and where they get found. To be clear, no one likes bugs – they are no fun for programmers or clients. We try very hard to write bug-free code, and if the client doesn’t want to pay for testing, we will try even harder to find bugs in the time we have. But as we mentioned previously, all programs have bugs. They are a natural part of the life cycle of all software. The choice is whether to pay for testing upfront, or pay for more bug-fix time later on.

Step 4a - Bug Fixes (After Delivery)

Testing usually finds and fixes 99% of all obvious bugs. Unfortunately, there are several types of bugs that can only be found after the software is live. These bugs are intermittent in nature, or only occur under a combination of factors. Here are a few examples of after-delivery bugs:

  • The program works perfectly during the day but dies every Tuesday at 2am
  • The program works perfectly for 25,000 users, but two of these users get errors when entering data
  • The program works as designed except for the two users who have Netscape 4.2
  • The music player works for 98% of all visitors, but 2% report that they cannot hear sound when they click play.

To address “after delivery” bugs we set aside a small reserve of hours in our project plan. These bugs are often the most difficult to track down, and take the most time to replicate so we can test to ensure they are fixed.

Step Five - Installation and Support

After testing is done we will arrange to install the new software on the designated servers. We complete some or all of the following steps

  • Complete a final “get” from the source code control database
  • Move all required files to the server
  • Configure the web server, database server, and/or application server as required by the application
  • Configure firewalls, proxy servers, authentication servers, and/or DNS entries as required by the new application
  • Complete data conversion or migration if required
  • Install Microsoft or 3rd party applications / upgrades if required
  • Complete a quick regression test to make sure all major functions of the application are working
  • Deliver “turnover” documentation if part of agreed-upon deliverables

That’s it. The program is live and ready for use.

Wrap-up

Pretty simple, right? 

If you have a software project on which you want to sprinkle some of our hard-earned wisdom, contact us or call Rick Fessenbecker at 414-914-9102.

But Don't Take Our Word For It.

I’ve worked with several other web development companies and, in my experience, I have to say the Northwoods team offers the best value and excellence in customer service and experience. From the very start it was about creating a site that actually works not only for our clients but also for our staff. I highly recommend Northwoods for their quality work, skilled team, and excellent customer service.

- Natascha Malkemes, Director of Marketing, Lutheran Social Services of WI & Upper MI, Inc.

I just have a lot of admiration for the Northwoods team. This is world-class intelligence and quality. I don’t know how Northwoods managed to assemble so many excellent people in one place.

- James Shafstall, Digital Marketing Lead, The Vollrath Company

Powered by Titan CMS