In our previous post, we gave a quick glance to the software development process that I usually follow when building tools. Now that we have given the process a brief introduction, its time move into the first phase of development which is usually referred to as the software planning stage. This stage involves a lot of forward-thinking and it can be quite challenging sometimes. It is very tempting to just jump in and begin coding and figure things out in a "straight ahead" approach. I have tried this approach many times in the past, either by choice or by time constraints, and I usually end up having to rewrite the tool once I understand the problem a lot better. When I have taken the time to plan things out, things have always worked way better. Planning ahead is extremely useful.
So let's dig in and start planning this bad boy.
Problem Analysis
The first step when trying to device a new tool or script is to properly identify the problem we are trying to solve. This is the only way we can be sure that we are addressing the problem at hand. You might think, "well, thank you captain obvious", but it will surprise you how many people jump into trying to fix something without really understanding what needs to be fixed.
I usually start the process by writing down a statement which covers what it is the main goal of the application. For the MaterialX to Blender plugin, I would write something along the lines of:
The MaterialX to Blender extension will allow artists to import, export and edit MaterialX descriptions directly from inside Blender allowing for easy interchange of the look of assets with other DCC tools
No need to get fancy or extra "wordy". The above definition gives me a clear indication of what the final outcome of the project should be. It is also one of the bars that we will use to measure whether we have been successful in our project. It is natural to try to add more information to the above statements, but that would probably take us into the specification or requirements stage, so try to keep the main goal of your tool short and concise.
Spec or Story Gathering
Now that we have clearly defined the main goal of the tool we are about to write, the next step that I usually take is to break down the whole thing, or as much as I can at this moment. I try to write a very simple description of everything I can think that the software should do.
There are several ways you can go about this. Some project management techniques require very detailed descriptions at this stage. Sometimes going as detailed as defining the type of data that should be used or returned by methods in the system.
Personally, I am a big fan of the approach taken by SCRUM. One of the main philosophies of SCRUM is to minimize a large amount of upfront planning, mainly because it is extremely common for all that specification planning to go out the window once real development begins. Instead, SCRUM tries to get to workable software as soon as possible, therefore it prefers to define the tool requirements in sense of stories. What is a story, you might ask? Well, let's look at one really quick.
As a look development artist, I need to be able to export the look assocatied with an object into a MaterialX file, so that I can import the look into other applications which support MaterialX
Most stories will follow the format "As a ROLE, I need to ACTION THAT IS NEEDED so that I can THE BENEFITS PROVIDED BY THIS STORY". Stories are powerful because, in a simple and easy to read phrase, we were able to identify who the final user will be (this gives us context), what is it that they want (this tells us what they need) and how this solution will be used (why they need this solution).
This is usually enough to get started because we have the most important information available. If instead of the above story, we had a story which reads
We need to be able to export looks into the MaterialX format
We might be left with several questions. Why do they need this? maybe there is a different way to accomplish what they are trying to do. Who needs this? is it for programmers to write automatic pipeline tools? We don't really know, do we?
Another important feature of stories is that they need to include, either by inferral or by additional information, what the "definition of done" (DOD) is for that task. A DOD for the above story might read like this:
An artist should be able to select one or more objects, or all objects from a blender scene and export the associated looks into a MaterialX compliant document.
This additional phrase tells us what is the bar that will be used to measure the success or completion of the abovementioned task. In order to track the progress of the project, I have created a public issue tracker for keeping track all of the stories for the tool. Please feel free to read the stories and drop me a line or a comment if there are features which im missing.
Cheers!
