Click here to Skip to main content
13,894,085 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


1 bookmarked
Posted 24 Jan 2014
Licenced CPOL

Why Am I Developing This?!?

, 24 Jan 2014
Rate this:
Please Sign up or sign in to vote.
A question that arises if one works in programming long enough
If one works in programming long enough, this question undoubtedly arises. Let's set the scene. The project has been humming along for a while now. The team is becoming more and more efficient in its execution as they learn how to function as a group. A new request comes in for a minor change to a feature. Someone picks up the task and completes it in quick order. QA signs off on the change and it is released into the wild. At that point, the feedback rolls in and it's not good. Customers are frustrated and confused. The unanimous feedback is: "That's not what I wanted!" This is where organizations start to play the 20 questions game. What went wrong? Why did this happen? Was the request properly documented? Was it built correctly? Is it working properly? Sometimes the answer to all of these questions is "Yes." Still confused? Don't be.

To find clarity, stop focusing on what did happen and dig a little deeper into what didn't happen. The issue was in the request itself. Instead of understanding the purpose and/or need for the request, the idea was added directly into the product. Requests should provide a sparring ground for most companies, but unfortunately these suggestions/ideas are not commonly battle-tested. Most concepts are built on incorrect, incomplete, or invalid information. It all starts with properly defining the problem to be solved. Without this foundational step, functionality will most assuredly be built on shifting sands. Understanding the problem helps drive clarity toward the proper solution. This helps define the boundaries and creates criteria that define what the solution is and is not.

Defining the problem is part of a broader What?-Why?-How? conversation. Each of these should be clearly answered before any action is taken by a development team. The first two define what the change is and why the change is taking place. This work can be completed by various sources from business stakeholders to savvy developers. The "how," on the other hand, is defined by the technical staff only after the "what" and "why" have been clearly defined and vetted. This vetting includes verifying the solution isn't influencing the true understanding of the problem.

For instance, say a request was received to provide sorting on a screen. It's important to avoid the temptation to label the problem as, "The screen doesn't sort." Although the solution might ultimately lead to sorting, proper identification of the problem will lead to a better understanding of the user's true intent. This might result in adding additional filters or providing entirely new functionality. This saves time, money, and makes happier customers.

The next time a request rolls in, stop and take the time to ask the question, "What is the true problem?" Properly identifying that question will have untold savings throughout the development cycle. 


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

You may also be interested in...


Comments and Discussions

QuestionWhy Am I Developing This?!? Pin
Frans_5512929-Jan-14 9:59
memberFrans_5512929-Jan-14 9:59 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web03 | 2.8.190306.1 | Last Updated 24 Jan 2014
Article Copyright 2014 by Zac Gery
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid