Development SDLC Phase

Before you start writing code...

According to a Forrester Research study, IT professionals expect to spend as much as 76% of their budget on maintenance meaning their spending 3/4 of their budget to fixes bugs, repair the system, and keep it up and running.  That leaves just 24% for investing in new features and enhancements.  Something is seriously wrong with this picture! 

So how do we avoid producing poorly written code that is littered with bugs?  The answer is not just "more testing".  Good code is based on good designs which are based on thorough analysis.  That means during the development phase of the sprint, the team must reconfirm unknowns and capture important details that will impact the sprint development.  Before opening your development tool and diving into code, it's also important to design out your changes or features you're going to be constructing.  This design process will force you to think about how the code should be developed and save you valuable time on missing things that could cause bugs.  

Your System Exists in 2 States

What does this mean?  When completing your project in MIS 333K, many of you may have developed your solution simultaneously with your teammates in a single environment.  This can be extremely risky if one teammate overwrites another teammate’s code, or worse, or crashes the entire system.  What if you didn’t back up your work!?!  That’s why you must always think of your codebase and system in two states:

  • Deployed/Live/Production – This environment/system/code is accessible by your end users (aka – “in production”). The Production system is the “Golden copy of your code” that sits in its own environment.  We should put protections in place to ensure this environment is not tampered with by developers, and that only the tested and reviewed/approved code is moved here carefully on the agreed upon time.
  • Development state – Code should also exist in a separate set of environments and starts as a copy of the Production environment. In this codebase, we will build and test.  If something goes wrong in the development or testing environments, it won’t affect the Production environment.  All the ADCR tasks will modify the code in Development, not the code in Production. 

In industry, it’s the standard to use multiple environments when building a user story.  The Dev Sandbox environment exists on a Developer’s local machine (e.g. your laptop), and includes the necessary software development tools and test data required to construct the system. The Dev Sandbox environment duplicates a working codebase to the local machine, enabling Developers to exercise creativity and rapid development while not interfering with the clients’ stable production environment. Ideas, proof of concepts, and prototypes can be built in the sandbox without affecting the Production environments. Once code passes unit tests in the local Dev Sandbox, it can be migrated to a Development Integration Environment to ensure the code assembles with the larger codebase without error, and it can then be further tested.  Eventually, the code in the Development Integration Environment is moved to a Production Staging Environment for User Testing and Performance Testing.  Once the code is thoroughly tested and approved in the Staging Environment, we can deploy it to Production for users to access and use.

environments

Coding Standards

It's rare that a single system will be supported by a single developer for its entire life.  Because of this, it's important to establish standards and conventions for developers to follow when adding/editing configurations and code in the system. Before you get too far along in programming it's important to figure out what conventions and standards developers will follow because it will be harder to later change the code to match these later.   While all systems can differ based on things like configuration or language, there are some universal standards that can be applied to all systems, no matter the level of complexity.  Here are a few important ones to always consider

  • Commenting - Due to time restrictions or enthusiastic programmers who want immediate results for their code, commenting of code often takes a back seat. Programmers working as a team have found it better to leave comments behind to decrease the cost of knowledge transfer between developers working on the same module over time.  A comment should contain things like the following: Author Name, Date of Change, Description of Change, Why it's made (e.g. enhancement, fix).
  • Naming Standards - Giving meaningful names to your variables, tables, table fields, classes, methods, etc... helps reduce ambiguity and confusion.  It's also important to consider some formatting like camelCase or underscores_better_words to increase readability.  Also, use full words when you can (i.e. TruckWeightKilograms instead of TrkWeight) because it's more clear to future developers.
  • Keep Code Simple - if you can write code with fewer lines, then do it.  Not because it's less code but because it's less code for future developers to read and parse through.   
  • Avoid Hardcoding - Program code should not contain "hard-coded" (literal) values referring to environmental parameters, such as absolute file paths, file names, user names, host names, IP addresses, URLs, UDP/TCP ports. Otherwise, the application will not run on a host that has a different design than anticipated.  Hardcoding also makes it hard to reuse code.

Examples