GIGO

Ask anyone, even ChatGPT, and they will tell you that GIGO stands for "Garbage In, Garbage Out." It's a concept used primarily in computer science and information technology to emphasize the importance of input quality in producing meaningful and accurate output.

In essence, it suggests that if you input poor-quality or flawed data into a system or process, the output or results will also be flawed or of low quality. No matter how sophisticated a system is, if the input it receives is incorrect, incomplete, or inaccurate, the output it generates will reflect those deficiencies.

This principle highlights the critical need for accurate and reliable data as the foundation for obtaining valuable, valid, and dependable results from any computational or information system.

Okay, so most of us have heard this term, so why do most of us seem to forget it? I keep walking into delivery exercises, requirements elicitation, and general delivery practices, and keep seeing "garbage" as "input". My Development Team seems to always say, "Thank goodness we are in System Testing, now we get the real requirements!".

Another time I was just joining a team and on a call with stakeholders, and I heard someone say, "We never have defects". While I almost walked out, I had to stay to see their Release outcome. Sure enough, they were late on delivery, over budget, and had a plethora of Priority 1 and Severity 1 Defects.

Most projects or agile trains I see start out with at least an 80% Defect Injection Rate (DIR). This basically means they are missing 80% of the necessary Requirements to deliver the Client's ask. One time, I was invited to help the Team progress and they showed me 40 Requirements. I told them they were missing requirements and they questioned my assertion. So I asked them where their Reporting Requirements were. The response was essentially, "Ooops". 2 weeks later they return with 44 Requirements and proud of their progress. After all it took them 6 months to come up with the first 40 requirements.

So I told them to write a User Story. I am not talking about some Agile Story Form (actor, action, achievement (AAA + AC...). I am talk about a short story on what the client want the User to experience. After some laughter and rejection, they gave in and wrote the story. They actually did a very good job stepping through the expected User Experience. I took their story (10 pt font, single spaced) which was a little over a page, and told them I would be back to them in 2 days.

When I returned I presented, to their amazement, over 400 Requirements (story form AAA + acceptance criteria (AC)). We were still missing scope (requirements) such as Current Mode (CMO) and/or Future Mode (FMO), but it was a better start.

One of my favorite subjects in The Open Group Architecture Framework (TOGAF) is the "Conceptual Model of an Architecture Description". The figure shows a "Stakeholder" and shows they have different (1..*) Concerns, Views, and Viewpoints. Missing any of these can (will) lead to problems, missed opportunities, missed requirements, and "defects". In other words...Garbage (GIGO).

Can you get every requirement? NO!  Will you have Defects? YES!! The key is awareness of these factors. Plan for these things to happen. And most importantly...test, Test, TEST!

One last point; Do not get into Analysis Paralysis! Write a story AAA+AC the best you can in the shortest possible time, and pass to a QoS or Test Team ASAP. Architects or Consultants will look at your nouns & verbs and form a "Solution". This solution will lead to a Design, which in turn will lead to Code development. Your Testing Team, through Regression and other approaches, may catch issues early, but never count on that.

I will leave you with two quotes I laugh and love:

Consulting - If you're not a part of the solution,
there's good money to be made in prolonging the problem.

and

When the process is lost, there is good practice.
When good practice is lost, there are rules.
When rules are lost, there is ritual.
Ritual is the beginning of chaos.