As inSync 3.0 release nears completion and the action moves from development to release engineering, I get some time to reflect on how inSync has shaped up.
(Please let us know if you have any feedback for beta.)
Some factors proved very crucial in the development process – Usability First inSync team always kept usability ahead of everything else. Usability ensured that inSync features can be easily evaluated by prospective customers. A customer may or may not like a product, but that comes after she can evaluate it easily. No usability means no evaluations means no feedback and no sale. We would rather not have a feature than an unusable one.
Zero Baggage inSync started as a disk-to-disk backup. It does not have any baggage that carries with a tape backup with disk-to-disk backup feature. We also tried not to pick non-core features along the way. If inSync picks up a new feature, be assured that Druvaa is very serious about it. We would rather have a small set of well deveoped features than a plathora of half cooked ones.
Release Early, Release Often (RERO)- The Apple Philosophy inSync 1.0 was a small feature set, but a complete product. (Interestingly, a set of customers found that it meets all their requirements and continue to use it even today.) Note that RERO is not about the quality or usability of the product. It’s only about leaner releases, each with a small set of new features. RERO allowed us a rich customer feedback that helped us pick the next set of feature to focus on.
I’m not saying that we do not miss deadlines, but things are more predictable while dealing with a small set of features. RERO also implies seamless upgrades, which is an extra effort but much lesser than managing a big release. In essence, we would rather have a small release than a big one that never ships.
Team with Diverse Experience Druvaa development team has engineers with extensive experience working on Windows, Linux, systems programming, database programming, UI programming, QA development, you name it. Things would be different if all of us were brilliant system programmers but none knew how to do UI, or the other way round. I’m proud to say that inSync is a no handicap team and we strive to ensure that the product does not have any weak areas.
Python as The Programming Language Kudos to Guido for a wonderfully intuitive language and kudos to the python team for the extensive set of modules. inSync uses C/C++ when it comes to heavy computation or interfacing with the operating system. But in both the cases, we managed to keep the C/C++ code to lower level functions. The high level logic is coded completely in python. It allowed us very fast developement of good quality, highly maintainable, cross platform code.
Don’t Reinvent, Reuse The Wheel inSync uses Qt (PyQt) for GUI, PostgreSQL as database server and several other python modules. We picked these after extensive experimentation and analysis. We also contribute back any bug fixes and enhancements. It’s not about just reusing the wheel but choosing a good wheel and then making it better.
Please let us know if you have any feedback for the beta. Would be more than glad to take a look.