Deciding on the Right Software Architecture for you

A fresh set of eyes can be the needed ingredient to galvanize a reorganization. Being the new member of the Ubiq team positioned me uniquely in this point of view. It was during my introduction to the code-base that I made note, over and over, how the classes were cluttered and the methods too integrated. The code lacked any semblance of modularity or planning. It was shortly after my arrival that we began the restructuring and rebasing of the source code.

We began with two days of meetings discussing structure of the disparate applications: client-side (Windows, OSX, Android, iOS), server-side and web-based. These meetings ranged from methods of synchronization of the client-side frameworks to the positioning of our potential transition to new hardware. It was all-encompassing and sometimes, embarrassing. Our flaws were on display, fault was apportioned, but this enabled us to move forward now and into the future.

This process was enlightening on two levels. First, we quickly came to realize that an overhaul was required. If we were to adhere more strictly to programming principles and best practices our entire base was going to change. Second, we had to determine how we can avoid this/these issue(s) in later iterations, new applications or added features. We surmised that a process had to be developed whereby each new product is executed in a specific set of steps. Largely, this involves engaging in significant and relevant planning. As obvious as our conclusion may seem now, it was not apparent when we, as a fledgling company, set out. This planning had to exist on two fronts: structure and schedule.

The former of the two, structure, is vitally important to any early stage company. Our discussions centered around how to minimize development time. That includes business logic and user interface. Our thinking was that fixing bugs was of the utmost significance to our beta customers. In order to get them to extend our service we have to be able to show them that we are working on their issues. They want to see progress. If one of their issues is solved, invariably, that solves issues for potential future clients. This lead us to the idea that the more uniform the individual applications the more quickly a small team can respond to issues.

Ideally, all could be done in one language with one IDE. Failing that we can do our best to make knowledge of one application translatable to another. Our first decision was to amalgamate the convention upon with the software is based. We restructured on an MVC model. Second, we built up one structure that we were certain could be applied across all platforms. This meant having a single controller, a model of the stream and the view. Finally, we began our approach at the micro level. This entailed standardizing the methods of each of these classes. This culminated in closing in on the ideal by applying Qt.io to our PC applications – a synthesis of our Mac OSX and Windows code bases.
Contact Us!

Share on Facebook0Share on LinkedIn0Tweet about this on Twitter


You may also like

×