How we think, what fires us up
Every technology company has bias. If you're told otherwise, it's worth a serious pause. For Moxie Group, our bias is towards the Java and Linux ecosystem. Therefore, there is a large set of technology that we know well which we pretty much take for granted within that ecosystem. This foundational expertise includes operating system and database administration, various J2EE application servers, REST/SOAP web service development, messaging middleware integration, data persistence components, a myriad of page rendering technologies, etc.
This is the 21st century. Yet, an impressive amount of productivity is too often lost while engineers wait on long compile times and application restarts to see the impact of a code change, QA leads wait on cumbersome deployment processes, and managers sift through code commits and tickets to isolate system changes. We believe these kinds of productivity losses are unacceptable. So, we leverage technologies like OSGi to support rapid application development, continuous deployment techniques for keeping environments constantly up to date, and strategies like Gitflow to efficiently organize code changes around business priorities. You'll find this emphasis on efficiency makes every hour invested by Moxie Group a more valuable hour to your business.
We humans aren't particularly reliably consistent, and we get a bit vexed with rote tasks. Therefore, we're constantly seeking ways to take the human out of the equation in having to manage the software and underlying technology systems. So, we follow continuous integration principles for managing builds and deployments, utilize dynamic scaling of server components, implement fitting automated testing, take advantage of SaaS solutions for office infrastructure, rely on databases that inherently support multiple nodes, dynamically manage schema changes through software, implement automated cluster and message broker techniques, and whatever else we can do to keep our brains focused on the strategic business problems instead of repetitive tasks.
All computer hardware breaks down. Every software package has bugs. The question is how you plan for those inevitable failures. We take questions of fault tolerance, redundancy, and scalability seriously. That certainly starts at the network and server hardware, but needs to carefully permeate through each layer of the software stack. At Moxie Group, creating technology that is explicitly resilient to failures and high load conditions is a key aspect that we expect from every system, every engineer, and every line of code.
Pick up most software books and you'll find a huge amount of information on APIs, OOP design patterns, and system integration. Technology firms quickly become proficient in those areas of software; even though none of those are where real people interact with technology. It's been said that over 80% of software development is in the user interface, and we've certainly found that to be the case. Creating software that will amaze and delight the people that use it is a core passion for us here at Moxie Group. That passion drives us to care about things like visually appealing interfaces, minimizing the number of clicks to complete a task, eliminating clutter on a screen, and responding appropriately to the type of device the user is interacting with.
We don't build technology for technology's sake. A completely amazing piece of software is useless if it never gets into people's hands. Too many software projects fall into the trap of getting something 90% built, but never quite finishing that last 10% that it takes to get to a release. Success for us isn't achieved when we wrap up some technical deliverable; we're not content until the technology is in use and bringing measurable benefit to our clients. Therefore, we advocate and execute a project definition and agile development process that is predictable and ensures delivery every time. That means we work hard to manage scope, keep expectations straight, and get production-ready technology into our clients hands in incremental units.