Project Yuna Update – Lessons Learned

Introduction

The project is coming along great; many of the features set out to be implemented have been implemented. Features such as the text log, system time, event calling functionality, and much more coming down the line. But, with any features there comes complexity with public use.  Today, I’ll be talking about some of the thoughts that are going through my mind.

Public Use Complexity

Public use can cause the plugin and development to take unexpected turns, which couldn’t be accounted for otherwise when the public isn’t involved. There is only so much testing you can do internally.  A good example of these is requested features: implementing skipping text, control over the text speed, and auto text advance. These three features were not in the early build, but it’s something core to what people want from a VN. Every new feature adds complexity and that complexity has to be managed.

Managing Complexity

In my code base, I manage the complexity by breaking down functionality into their own classes. Breaking down functionality allows me to keep features manageable and easier to understand in the future.  While working on Yuna I had to break down creating a text log into three workable parts. The actual log text data, the representation, and then the functionality to bridge the data to the representation. Of course, I may have to make changes in the future. Which leads me to another important lesson: iterative releases.

Iterative Releases

Often times as a developer I don’t like releasing stuff early; it has to be completely done. Releasing something gives this feeling of” it’s done.” I don’t think that’s always the case; the work may only be the beginning. Knowing that is a scary thought.

I never was the person to write multiple drafts in school, so improving on existing work can be hard when it comes to rewriting the code base. But, I think it’s important to do; that work represents time saved and value for the people who use the work. If we can improve, or rewrite parts of it to get more value out of it; it’s a good choice to make.

Iterative releases are good, because we can see where we need to go, and that’s difficult in a vacuum. Because the only way to get better is to see where you could improve. That way you can make your work more awesome, and personally, I’d like to do that for myself to write code and a product that I think is good enough to get the job done well. Yes, you could make that algorithm better, but understand if the cost is worth it in terms of your time and the value that aspect brings to the project.

Leave a Reply

Your email address will not be published.