Face the Truth: Answer Our Questions
First, we have discussed the basics of being data-driven. Then we touched a few key issues. Finally, we created a small application that can help us in highlighting some key features of software and development principles.
In the next few posts, I will outline a technique I have used successfully since I developed it around 2005. But first, what’s the issue with the code we have so far? Isn’t it something that everyone is working on every day? Sure.
To understand the underlying problems, we first need to analyze what we have so far. We’ll use a selection of the questions from the first post to understand how it works. Can we do it? Of course, we created a data-driven application.
What kind of data do you intend to store?
We store tasks. We associate tasks with their summary. We also keep track of the status of a task using a predefined list of available values.
Can you split them into smaller chunks?
We have chosen to go with only two simple properties. There are two natural options here
Handle them in one structure
Handle them separately and somehow define a new attribute that will create a connection between them.
I hope we can agree that the second option is hypothetical.
Where does your data come from?
Task properties come from the user. They will fill out the summary when they create the task. Then they can change the task status as they wish. So data comes from the user.
Do you have single or multiple sources?
We don’t have any other data to store, so we have only a single source.
Are your data collected once, regularly or irregularly?
Data is collected irregularly. We don’t know when the user will create a new task or decide to change the state of a task.
Are you prepared to handle errors in your data?
Although we have started to react to the error paths, we haven’t done the work required to communicate meaningful errors. Other than leaving the summary empty, we don’t check for data integrity. Also, we don’t have a plan for checking status changes other than ‘new’ is assigned when the task is created and ‘done’ is considered as the final state implicitly by the UI.
Will poisonous data break your application?
Our application consists of two main components:
The backend has more advanced techniques. For example, you cannot run poisonous MySQL commands through code injecting. But it’s not protected, and through the open API, anyone can access all 3 endpoints mutating the data underneath.
Will users complain about errors?
Users always complain about errors.
How do you intend to visualize your data?
We have used a form and a list to capture and display information about the data stored. Also, we have used a dropdown list to display and enable the change of the status property. And we are displaying the number of finished tasks, so the users can follow their progress.
Can you make sense of your data or it confuses you when you look at it?
As a first iteration, it’s quite straightforward. But it could be improved by using colour and/or icon depictions of statuses, grouping the tasks by status, or enable the user to create a priority list of the tasks. And we haven’t implemented a required feature of grouping the tasks into projects.
And don’t forget those end users, who like to delegate their task management to colleagues.
Does your data structure enable you to make decisions based on the collected data?
If the only thing we need to know, what’s ahead of us, and what tasks have we completed so far, we have this information. But we don’t have information that would enable us to plan timed roadmaps. We don’t have estimations, users, and a lot of other things that would enable us to do more with this software.
Will your data mutate over time?
Yes, and that’s the main purpose of this software.
Is it intended or misbehaviour of your system?
Of course, it’s intended.
Is it automated or user-driven?
Users create new tasks but setting the initial status to ‘new’ is automated.
Do you need extra processing between data collection and presentation?
We need to store it to a database. It is debatable if it’s part of the collection process or the data flow. In my opinion, it depends on the structure of the software. If we were to send the data directly to the database from the UI that it’s a collection. As we are processing it first on the backend – to check for data injection – it’s processing.
Can you communicate the mutation of data through the presentation layer?
When a user adds a new task it’s immediately appended to the list and the selected value of the dropdowns reflect the status changes. So, we can consider we’re done. Unfortunately, the answer is still no. If you open the page in two browser tabs, the information is not synchronized unless you update the page in one of them when you modify anything in the other.
In the first post, we have identified how to separate the software into 4 distinct components. We made up questions, that helped us verify our solution. And using this process, we highlighted some key issues with what we created so far. We can now create new goals for ourselves to upgrade and improve on the codebase in the future.
It’s one way to verify our progress and identify possible pitfalls. This way we can make sure, we deliver what the user needs, and avoid any side effects.
In the next post, we’ll talk about the necessity of estimates. Until then, try to analyse one of your projects. Can you identify something you can improve on?