Always Use Protection: Why Adequate Documentation Often Saves A Failing Project

Mind maps allow a software developer to intentionally consider a customer’s needs and desires. When utilizing a mind map, a developer listens and records a customer’s statements and converts them into a visual working plan for a project. I enjoy using mind maps because they encourage a developer to build rapport with a customer. The customer remains the focus, and the software developer maps out a visual plan the customer can easily understand. By reflecting the statements back to the customer, the developer provides an opportunity for feedback from the customer increasing the likelihood that the software developer designs a system that meets the wants and needs of the customer. The customer feels supported and involved in the process.

A user story allows a developer to quickly consider how an application applies to multiple user scenarios. A paragraph describes the initial user need and project idea. While a user story does focus on the wants and needs of the customer, it does not build rapport with the customer or make them feel heard. A mind map differs from a user story because it reflects the words of the customer back for clarification and displays the information in a visual format for project discussion. Providing opportunity for feedback during the brainstorming phase of a project helps a customer feel involved in the process.

While either user story or mind mapping techniques provide positive insight into the wants and needs of the customer, I utilize the techniques differently. In my own development journey, user stories allow me to brainstorm a project that I want to create on my own and expand to fit multiple scenarios. Creating multiple user stories allows me to brainstorm comprehensive, reusable products. Alternatively, mind maps allow for direct interaction with a customer I want to build a specific application for. While I will still consider user stories during the process to ensure scalability, I prefer to provide visual, direct feedback to build rapport with customers by intentionally involving them in the project and creating a record of the project discussed in the consultation. While mind maps and user stories play different roles in my software development journey, other developers may choose to utilize the techniques differently. Techniques should always assist a developer’s process. The moment a technique fails to assist a developer or a customer, it ceases to provide value to the relationship. Developer preferences allow for flexibility and personality to improve the software development environments and relationships.

While user stories and mind mapping techniques open the discussion and provide feedback for customers, use cases provide a detailed description of a system's interaction with a user. Use cases provide detailed documentation of how a system will operate. They strengthen the relationship between the software developer and the customer by providing concrete insight and involvement with the project plan. Requirements simplify and enforce the agreed upon steps while discussing the criterion that will show a project is complete. A developer could choose to forgo this step; however, requirements prove an important part of my development process. Starting a project without an agreed upon plan or goals along the way to reinforce progress throughout the project life cycle would leave me open to legal issues and additional unnecessary stress. Updating documentation, mind maps, use cases, and requirements transforms into a quick, thoughtful process that includes project templates. While these techniques might seem overkill to some developers, I operate best in an environment that offers feedback and legal support. Ignoring the requirements list and only updating the use cases leaves a customer feeling under supported. Without proper care and direction a customer might even feel deceived. Because I have personally been deceived in the past, I see a need for documentation. 

Quality assurance on a project produces happy customers and fulfilled developers. While some developers might feel stressed by documentation and may need another team member to provide additional support to ensure adequate legal protection and customer support, I enjoy documentation as a feedback tool that provides direction, stability, and fulfillment to other developers and customers who feel overwhelmed and irritated by the documentation process and benefit from my help. A good developer could produce a fantastic product that the customer does not want because of disregarding necessary documentation. A quality developer might be left legally unprotected and might not be properly paid for a project because the necessary steps to ensure due process were cast aside. While a project could be completed without following these techniques, the likelihood of making a mistake decreases when a developer takes the time to focus on the customers wants and needs while ensuring appropriate documentation exists to protect their project.

Comments

Post a Comment

Popular posts from this blog

SalonAboutBeauty: Less Integration for Consistent Styling Across Components

Ensuring Consistent Variables Less provides several advantages for organizing CSS to ensure consistency across a website. The variables.less file defines reusable properties that allow a developer to easily communicate and maintain styles according to a style guide or theme.  The Less Web Development Cookbook describes properties in the variables.less file in relation to other programming languages: “Variables in Less are defined as the equivalent to statics in other programming languages. You assign a value to a variable once and use it everywhere in your code” (Meyghani & Jobsen, 2015, p. 50). It suggests that less allows a developer to set properties, such as colors and length, to variable names that retain their meaning and can be used everywhere in the code. Examples: @base-color: red, @primary: green.  By providing these definitions in a central location, developers create code consistency in all areas of the website. Creating an Organized File St...
Read more

Why “Human Error” Is Usually a System Design Problem

In complex systems, failure rarely comes from a single bad decision. It comes from problems that evolve slowly, cross boundaries, and remain unresolved while everyone involved behaves reasonably. Managing risk in these environments means managing trajectories, not just incidents. When ownership is divided strictly by role, function, or severity threshold, gaps are inevitable. Those gaps are where issues linger, age, and quietly accumulate risk, not because they were ignored, but because no one was responsible for carrying them forward end to end. This is common in healthcare, where delay is often necessary. A patient may require observation, referrals, or time to clarify diagnosis. The failure is not that care takes time; it is that the trajectory of care becomes fragmented. Each clinician escalates correctly within scope, yet no one owns the evolving picture across visits, domains, and decisions. The patient is evaluated repeatedly, reassured locally, and sent away without continuity ...
Read more

Challenges in Prosecuting Deep Web and Darknet Crimes: The Case of Ross Ulbricht and the Silk Road

  The deep web represents online information that is not easily accessible through search engines. Prosecuting crimes on the deep web is no more challenging than prosecuting crimes for any standard website because law enforcement can still track the user's location through a domain or IP address. Alternately, the darknet poses a challenge for law enforcement to address illicit activity because while the darknet is a web-based system, it is accessible only through the Tor protocol that encapsulates HTTP and HTTPS traffic, much like a VPN that hides a user’s location and identity. The Tor protocol, often called the Onion Router, contains methods for encrypting and routing traffic between peers. The purpose of the Tor protocol is to make web browsing anonymous by routing each request through multiple peers and altering encryption at various steps until the request reaches its destination. Subsequent requests may hop through different peers, making traffic appear random, unpredictable,...
Read more