Search
  • Gábor Csepregi

Capturing Data To Understand Data

In the previous post, I simply defined what Data-Driven Design is. I did so mainly by asking questions. If you're waiting for me to answer them now, sadly, my answer is that it depends on the nature of your project. There's no one right solution for every problem.

What I intend to introduce you to, though, is to identify some patterns, where you can ease your development process, and remove repetitive, error-prone processes. This will enable you to have a clean structure at the beginning when the project scope is still flexible. The best would be if you can create the application right in front of the client while capturing their requirements.

To do so, we will create a project for an imaginary client. I will share the complete source on Bitbucket later. We will use Angular 9 for the frontend, C# Azure functions for the backend, and MariaDB for a database. Also, for authentication purposes, we will rely on Auth0.


Disclaimer: Any similarities of the following project description and any existing project out in the wilderness is just a coincidence and not intended.


Our imaginary client wants a custom-built task management system. No matter what we offer instead from the great palette of existing solutions, they already made up their mind about it. We cannot cheat we need to build everything from scratch ourselves. So, we could start the analysis interview like:


"What's the purpose of the software you need?" - the business analyst asks. "We want a task management software that enables us to plan our projects and workload better." - the analyst takes notes: tasks, projects, workload(?). "How would you describe a task?" "A task is a unit of work. It has an id so that we can refer to it around the company. It has a summary, a detailed description, a creator, an assignee, a created date, estimated time to finish, actual work logs, the status of the task, and history for every change in any property of the task."

“I assume creator and assignee are employees, right?”

“Yes. But wait, no. We have some external users, who are permitted to create tasks for us. And while we’re here, I’d like to mention that some of our employees like to delegate the creation of their tasks to co-workers. We discourage it, but to keep the current flow in place, we would like to have the ability of users to create or modify tasks on behalf of someone else.”

And so on, a simple conversation between the representatives of the client and us. We are all aware of the limitations of such conversations. What is obvious for one can mean something else for others. These are the limitations of the spoken language itself.


On the other hand, if I write:


public class User {
    public string Id { get; set; }
    public string Name { get; set; }
    public ISet<Cap> Caps { get; set; }
}

public class Cap {
    public User User { get; }
    public Employee Employee { get; }
    public ISet<string> Permissions { get; }
}

public class Employee {
    public string Id { get; set; }
    public string Name { get; set; }
}

public class Task {
    public string Id { get; set; }
    public string Summary { get; set; }
    public string Description { get; set; }
    public Cap Creator { get; set; }
    public Employee Assignee { get; set; }
    
    // rest ommitted for readability
}

Much cleaner from a developers point of view but hard to understand for the business analyst and the client. I think everyone would agree that the most time of software development is spent on communication issues. To translate the dialogue into the code above. (And that code still has no information about what summary means!) Could we turn requirements into data, and have some nice algorithm that turns it into the software the client wants?


In the following posts, we'll see if it's possible.


21 views

©2020 by Gabor's blog. Proudly created with Wix.com