Software Roadmap is a concept that many underestimate and not many can really define. What exactly is a software roadmap? What does it look like? When to use it? It’s often hard to find answers to these questions. So we decided to share our experience in building and maintaining digital products on the examples of Ultimate Software Product Roadmap.
Ultimate Software Roadmap exemplifies how things should be done:
At first glance, you may think it’s just another Gantt chart with some pretty colors and icons. But it’s not. The main purpose of this kind of visual representation of project development progress is to identify the current state. And plan ahead without the need for lengthy documents or meetings with numerous participants (graphics get everyone “on board” faster, whereas the text often leads to confusion, conflict and miscommunication). There’s a reason why visual management solutions are successfully used by large corporations such as Airbus, Boeing or NASA.
Ultimate Software Roadmap is an amazing tool that serves both for planning and tracking project development progress . It allows us to monitor how fast we’re moving towards our goals in real time.
We’ve been developing it for almost two years now; there were several stages of growth every time new challenges emerged (more on that later). We started with MVC + ASP.NET Web API + KnockoutJS , then rewrote the front-end part using ReactJS, which gave birth to an MVP version of this product; soon we’ll hit the RC release, which will be followed by a 1.0 version.
Since we’re now done with the first part of our product development and decided to “reboot” it (i.e. rewrite it). I’d like to share some insights on what we’ve learned over this period. Especially that there is no one-size-fits-all solution and everything depends on the project’s nature and team’s skills:
1) Speed: Big projects = Big problems !
Our company has been growing fast recently; as far as software engineering resources go, they are limited in our small city; thus every developer is responsible for several different products (for example, I’m working within at least 4 separate projects). Hence, when we decided to build our own game engine, the idea was for this project alone to be able to stand up by itself. Yet results are very disappointing so far. Many components have been written twice over since their initial version wasn’t intended to cover all needs.
2) Designing your own engine is hard !
Designing an engine requires a particular mindset which is not easy to acquire nor master. Especially that there are always several smart people behind you saying “Don’t do it that way, do it another way”. Or “It’s better if you just did it my way”. It usually takes years before finally find out what works best in your style of work. And environment plus being able to manage all the chaos that this type of endeavor implies.
3) And designing a nice engine is even harder !
To get to a really polished state there are many fronts you have to face. It’s not simply coding, nor simply designing one either. For instance, your code must be flexible enough to allow easy modification from others. Or from yourself at a different point in time. It must also be documented so other people can see how it works. And maybe cooperate with you somehow on the project without actually being physically present next door to you :-). You have to deal with memory management issues for instance. When going through all these points, there are several ways to design an engine and each has its benefits and drawbacks. If you’re lucky enough to be supported by a big company, you’ll probably have time and people to do things right; but that’s not the case for most of us.
4) MODIFYING AN EXISTING ENGINE
This is the easiest path to go. Instead of reinventing the wheel, you use an existing engine and build your game on top of it. Also it’s a good way to learn how things are done in general in that particular engine or technology. Because eventually you won’t only be using their classes but also writing your own. Either by extending existing ones or by creating new non-related structures.
An example would be coding in C++ to use Direct3D for graphics while talking to OpenGL for mesh manipulation operations. The overall benefit here is that you don’t have to worry about anything else except your game code itself so if someone comes up with a question about what this function does. There’s a good chance you’ll find the answer in the engine code or documentation. Just make sure you don’t mix up your own code with theirs. Because that would create a lot of trouble trying to figure out what’s wrong and why it doesn’t work as expected.
Also read: How Sales Enablement Software Helps You to Close More Deals?
