From The Programmer’s Desk: Developing For Others

Hey everyone, Volvary here. Today, I have another chronicle for you coming from deep within a programmer’s mind. If you have ever developed tools for others, you will have a well-defined ability to identify with what follows.

We have been developing tools recently to help our non-code savvy team members work with assets inside of Unity. In midst of all of this, I compiled for myself what I consider the top 3 recommendations when developing debug menus, editors and other tools for your designers, artists, users and, to some extent, for yourself. After all, you don’t want to have to go through all that code when you need to utilize such a tool again 3 months down the line. So without further delay, I would like to present to you those 3 recommendations:

DEVELOP FOR CHILDREN.
This may sound harsh at first but it is true. If you design your tools for other code-savvy users, your tools WILL break. “I don’t know what I did, but it broke.” is one of the phrases you want to hear the least. So save yourself some time, develop from the start with the mindset of baby-proofing your tools so that they can’t be broken easily.  If you know some values break above or below certain points, restrict them. You know how some values can break the expected outcome of the tool if misused? Hide them behind a protection so that you limit their access or revert the changes made manually.

DEVELOP FOR PEOPLE WHO HAVE ONLY A BASIC UNDERSTANDING OF LANGUAGE AND OF THE PROJECT.
If you have never developed tools, you would be surprised how out of the loop certain persons are on projects you will work on. Hearing things like “What does ‘Cluster Count’ do?” is something you learn to avoid over time. How? Use concise names for anything the end-user will see (clustCou is obviously a no go), add longer Tooltips than you think you need. (You would be surprised how effective “Number of Clusters spread across the body.” is at explaining your Cluster Count variable. “Number of Resource Clusters spread across the celestial body,” would be even better. If it starts to feel superfluous, you are entering the green zone.

MAKE IT EXPANDABLE
As with everything when working with a team, other team members, artists, designers and project leads, will always have different ideas than you. Often times, this will mean more tools to facilitate their work. As a tool programmer, you are near the top and the bottom of the importance pyramid at the same time in your projects. If you perform well, you will be the least of anyone’s concern and will slightly have to edit things for each new information others need to play with or each new function they need. If you work in a less than optimal way, you might be slowing down others as you try to create something new for their needs. By making your tools expandable, you are giving yourself a service for the future.