A feature is; the tool fulfilling a user’s need. As a soft example, someone requested a ‘time-out feature’ on displays that have been inactive for a while. The time it takes to time out is also user defined. That is it, a basic feature. It has a behavior (sleep the screen) and a constraint (user defined delay). In software, the development cycle is elaborate even for the simplest of actions and here we will explore why.
For starters we will need to set up a typical(generic) cycle to elaborate the typical time-out feature that is now our demonstration. It will provide a solution (feature) to the problem that this feature is to solve and the we have it; our first step:
1) Problem Statement
This is the direct scenario that the feature will have an impact on. In this case it was summed as “Improve Monitor Power Consumption” and during the brainstorm, the following suggestions were pushed for solutions;
- Get the user’s attention if about to sleep. It was suggested that the monitor momentarily dims after in-activity to try and trigger user action. If none then proceed to monitor sleep else restore brightness.
- Create an interface for the user to set a period beyond which the monitor will be deemed ‘in-active’ and trigger the function above.
2) Planning
At this point the developers set about making this a reality. They have another brainstorm; this time on a technical level. First is to divide and conquer the task at hand. Everyone picks out the tasks around their specialty.
- Front end developers set about designing the user interface. This is what the user sees during operation.
- Back-end developers get to developing the functional elements of the system.
- A full-Stack developer will oversee how these elements interact.
3) Development
The software gets built at this point. Multiple languages are used to accomplish the tasks at hand. Why? Because languages have their specialties too. Almost any language can achieve almost anything however; it is just easier to perform tasks using tools designed for the task. It’s not laziness; that’s efficiency.
Ordinarily, this is the most difficult phase. It is where most of the work lies.
For example; testing will be done in this phase. Edge scenarios are thought of in advance. This are rare activities, not expected to happen or be common but must be anticipated. Like; what happens if the user enters a value too small? Solution: have five minutes as the smallest possible time limit.
4) Approval
The feature is first installed on a few machines for testing or ‘staging’. The machines are picked from the widest possible variety of applications. Mobiles, desktops, watches just to mention a few. You are basically looking for edge scenarios in the real world.
If the feature performs as expected here, it is pushed to deployment. If does not, feedback is provided and pulled back to the previous step.
5) Deployment
Make the feature available to all users. You may choose to do this in whatever strategy. You could pilot it out (make it available to a section of users) or universally deploy it. The latter requires a bit of courage and luck.
If a problem is noted, then the a patch is written and pushed to production right away.
6) Monitoring
This will happen throughout the feature’s existence. Suggestions will be pushed to approval and then proceed to deployment.
7) Iteration
Say users report screen dims and shutdown while watching movies. The first step is to reproduce the error to get to the reason why. No errors were detected however it was noted that during problem definition; user activity was automatically detected by keyboard press.
However, some programs were meant to just stay on display. So the solution was improved so that certain programs too could reset the time-out timer every time they did something. The solution also covered displays meant to display static information.
The said cannot be treated as a patch as technically, the previous version cover the particular problem statement. This is a new version of the feature. It is given a number so that even the users too; get to choose between which versions to use.
This is not a patch as the former iterations were. This one goes through the entire process from the top. This time things are expected to proceed faster since everyone is already familiar with the general solution layout.
There you have it. A feature from scratch to versions of it.