Why Every Indie Needs A Developer Ninja

In this latest piece from indie.ninja, two industry experts with experience in both software development and the music business outline some important rules for successfully implementing effective project development into your work.

Guest post by Constantinos Mavromoustakos and Ray Canapini of Indie.ninja

There are many different jobs in the music industry, but knowing who to hire and when to hire them requires thought and planning. The needs and budgets of developing artists and labels aren’t the same as those for established ones. Making the right decisions and hiring the right people is where indie.ninja comes in. “Why Every Indie Needs A Ninja” lets you know when it’s time to bring in a professional and how they can help take your career to the next level.

Today’s guest post is by our co-founder Constantinos Mavromoustakos (we call him Gus) and our design ace-in the hole, Ray Canapini. Both have spent years in the software development world and also around the music business, so they bring unique perspective to this project.

Of the projects we have worked on, there are a few key tactics that are a must with any project that involves people (and that’s pretty much all of them.)

Make A Plan.

People love talking, we’re social animals. We love discussing and philosophizing and shooting out ideas, but until they are documented/written down we can not be certain that we are all referencing and talking about the same thing. Having a definitive thing to point to and have a discussion over is priceless and will save you a lot of time. It will also avoid problems down the line. Today’s designers use tools such as InVision, Sketch, Slack, and the almighty pencil and paper. Whether it’s a napkin sketch, a simple flowchart, or a clickable prototype these methods enable able us to solve problems sooner and iterate leading to better scoping.

Communicate effectively.

Music people are creative (and from my experience, a little ADD.)  While the ideas and vision are great, their skill set isn’t product development, coding or UX. Just as tech won’t assume how to tell someone how mix their record or how to market an album, we don’t expect you to assume what we do is a cakewalk. Both sides in this are wired differently and speak very different languages. So planning and clear communication is paramount when working in music, and proceeding with caution is the name of the game.

Set expectations.

As the technology, we cannot simply expect people to know how exactly long it will take to bring an idea to life and into a usable product that you can interact with. We (myself included) have walked away from meetings disgruntled and asking “do these people think it is like turning on a switch?”. Ninety-nine percent of the time the issue with communicating with non-technical people is that they do not understand the complexity or why talking shortcuts will hurt a project in the long run. You must have patience and learn to explain in non-technical words what you are doing. As tech, we all love throwing on our headsets and blasting away at the keyboard to produce beautiful code, but if we cannot explain what we are doing or take a time-out to explain the problems we will encounter, then the ‘others’ will have good reason to think that it is just as easy as throwing a switch.  Talk early about what the end goal is and how long it will take. If people start adding functionality then the time it takes to do it grows with it. If the functionality is unrelated do then push back on your business.

Keep It simple.

Big and small companies try to build the most complex systems from jump and wind up getting bogged down in patching holes or fixing bugs. It’s better to crawl before you walk, and that’s why understanding the business goals of a Minimum Viable Product (MVP) is key.  Developers are hammers, so every tech problem represents an opportunity to try to solve it with a technology nail when the easiest answer might be “we just don’t need this now to support our mission.” Designers will come at you with some crazy shit; it’s their job to come up with ways to make it easier to the users. The problem is that the fancier your UX gets, the more complex your code gets. If you have limited resources and spend too much time focusing on UX instead of how your system works, then you will wind up having an amazing looking product that shits on itself every 5 minutes because you skipped out on writing tests or took some other shortcut somewhere else to save time. Talk to your designer and explain your pain to them and offer solutions. Often times the better solution lies somewhere in the middle.

Watch the scope creep.

If you don’t keep it simple? Your business will likely fall victim to what we in the tech space lovingly call “scope creep.” Scope creep is the practice of starting to do one feature and it all of the sudden encompasses a number of unrelated features that can take an entire team (sometimes the whole company) completely off track. If you’re paying for development work, that’s money being burned. If you’re a dev, it drives you nuts because random tasks are always flying in with varying degrees of hair-on-fire importance. (Just like the rest of the music business?)  

Iterate.

Don’t spend an enormous amount of time getting things perfect before you show it to people. Get it in front of your team early. Even if it’s shitty and buggy. Have them look at it quickly and iterate through ideas. Sometimes it looks great on paper but when you actually go to use it it does not make as much sense. Being agile helps people determine if something needs to be adjusted for it to be more useable (or sometimes if it even makes sense as a feature at all). A good example of this that we encountered recently with the indie.ninja platform is that we wanted to save users save on CC processing fees and leverage ACH. The issue was that until we got a little into the weeds, we didn’t realize that our payment system would not work with our escrow system if we used ACH in the way we thought. We found out the issue fairly early in the integration when the team tested it, the incompatibility became apparent.  So that feature was punted to a future time when we could re-address it along with some other streamlining features along the same lines.

Track it all.

Project management tools such as Pivotal really help with all the tasks involved in putting a build together and squashing bugs. Things get lost in translation or sometimes just escape our heads, given our very limited capacity to hold information (some of us less than others, with myself being part of the former group). When creating tickets for each job, it’s key to establish a common language with your team. Vague sentences can be interpreted differently depending on who is reading them. If you and your team have a set of terminology there will be less room for making incorrect interpretations and assumptions. When writing these features or bug fixes there are three very important things that MUST be captured: Who, What and Why. you have to know who you are building this feature for. If you have different types of users or even similar users that might interact differently than other users then identify them in the Who. For example, a Ninja in indie.ninja is a type of user, but a student Ninja is a subset of those users who have slightly different interactions with gigs and other users. The title of a story should also be kept simple and clear: “As a ninja I need to apply for a gig” and more detail under the ticket provides necessary detail on how it should work.

We can’t bridge the worlds of tech, design, and music in one post and there are tons of great resources and blogs, such as Smashing Magazine, Scotch.io, and A List Apart to help you find out more. But hopefully we’ve given you a bit to chew on, and a window into some of the best practices to build a successful music tech product.  

Like what you read? There are dozens of experienced designers and developers at indie.ninja. Apply now for the beta.