Alright everybody, let's go ahead and get started with this project of writing a MaterialX I/O workflow for Blender3D. As stated in a previous blog post, I will be writing this extension and sharing with you guys the whole software development process. I'm going to try to do most of the videos live, and as un-rehearsed, as I can without wasting your time. This means that there will probably be mistakes and corrections that will happen as we move forward with the project.
Now, since the whole point of this exercise is to help those who follow us grow their technical knowledge, I will ask that if you find a mistake, or if you know of a better way to do something, please go ahead and list it in the comments. As long as your comments are courteous and constructive, I will try to address those notes in the next post.
Alright, enough intro, let's get to it.
Whenever I am faced with a new script, tool, shader or any other task which requires software development, I like to take the project through the following stages of the software development process. Others TDs might use a different approach and different steps. These are just the steps that seem to work best for me and they seem to reduce the amount of time spent correcting mistakes in the development of the project. The stages of development that I follow are:
Problem Analysis
Why are we building this tool? What is its purpose and what is the problem that we are trying to solve? The more we know about the problem we are trying to solve, the better we will be able to target a solution.
Spec or Story Gathering
Our tool or plugin will need to do many things. What are these things? What are the different actions which the user will need to perform in order to get a useful result from this tool? At this stage, we are trying to identify what are the features of the tool we are trying to build. We don't need to go into the details of how each of these features will be implemented, we just need to identify all of the features so that we can prioritize them and begin creating a list of tasks to be done.
UI Prototyping
Once we know all of the features of the tool we are trying to build, we need to figure out how to present these features to the end user in a GUI (graphic user interface) that makes sense. I have seen many great tools die because their GUI was just too hard to use or it just "made no sense". We also need to find our answer in the most time effective manner we can. Creating quick wireframes or mockups is a great way to iterate over the UI/UX of the application without committing unnecessary time to it.
Design
Here is where we begin to figure out how we are going to implement all of the above features in a way that allows our software to be easy to read, easy to debug and easy to maintain. The designing of software can be quite challenging and it does take time. It can also guide us into design paralysis, which is when the whole project seems to stop because the design keeps getting tinkered with by the engineers. It is a bit hard to find the balance of how much design is too much or too little.
I tend to like to design the most important parts of the tool, the broad strokes. I try to follow the 80/20 rule which when applied to software design, it would say "80% of the value (features) will come from 20% of the effort (design)"
Exploratory Coding (R&D)
Pretty much every tool that you write will have at least one feature which represents work that is a bit new, that requires a little bit of tinkering to figure out how to solve. I don't really like referring to this stage as R&D because I feel that such term is for bigger, greater things which have higher degrees of unknowns. I rather refer to this stage as the exploratory coding stage.
The main goal of this stage is to figure out how all of these unknowns will fit into the design that we have created. It is not uncommon to need to go back to the design board after doing some exploratory programming and that is the whole reason for doing this step. We wouldn't want to build a bunch of software only to find that the unknown parts of the project don't fit into what was built.
Development
At last, we get to roll up our sleeves and get to code. If we have done the previous steps properly, then this part should go much faster than expected. Granted, we can still run into tough programmatic problems while developing, but most of the "big thinking" has already taken place, so this part can become much more enjoyable.
We will cover a development approach called Test Driven Development (TDD), which is the approach that I favor. It tends to make development slow at first, but it always pays off in the long run.
Release & Maintenance
Once our tool is ready, its time to release it to the world. We have put a lot of work and effort into this tool and it would be sad to see it go unused because we forgot to package it all up and put a pretty bow on it. You see, if you just throw this code out into the wild without sharing with people what it does, how to use it and a little bit of how it works, there is a good chance that the tool will not get as much traction as it could have.
We will cover quick ways to document our tool in a way that is easy for coders to follow along and also for end users to jump right in and get productive. We will also discuss the maintenance stage which will shine a light into the benefits of following a TDD approach.
Conclusion
Each of these topics requires a bit of a deep dive, which is why I after consulting with some close friends, I decided to make this a multi-part series. Please make sure to come back to this page in the future or follow me on LinkedIn or Twitter.
Cheers, Y'all!
